ICEfaces
  1. ICEfaces
  2. ICE-6453

Maven builds for portlet versions of sample apps

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.1
    • Component/s: Sample Apps
    • Labels:
      None
    • Environment:
      ICEfaces 2 maven build portlet portal
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.)

      Description

      We need to adjust the way that the portlet examples are built so that they are more Maven friendly. Currently, building the non-portlet versions of the apps includes the portlet files and dependencies.

      - Portlet resources, files, and dependences should not be included in the non-portlet builds.
      - Pluto requires a special Maven task to run and inject stuff during the build in order to have it deploy properly.

        Issue Links

          Activity

          Hide
          Deryk Sinotte added a comment -

          To better support Maven, we decided on a strategy of having separate project directories for portlet examples rather than simply injecting the few portlet files we have into the existing servlet examples. So the new layout for examples that have a corresponding portlet build should look like:

          sample/ace/showcase
          sample/ace/showcase-portlet

          sample/compat/component-showcase
          sample/compat/component-showcase-portlet

          sample/core/chat
          sample/core/chat-portlet

          Inside each directory will be a build.xml and a pom.xml, with common build info factored out to the appropriate level (e.g. common to all samples, common to all portlets, common to compat, or specific to that example).

          Moving stuff around this way necessitates an overhaul of the ant scripts for building the portlets since they are no longer simply injecting a few files into the existing non-portlet.war.

          For Maven, the build-helper-maven-plugin is used in the portlet poms to allow pointing at multiple source directories so that the portlet build can simply refer to the source in the servlet folder.

          For Ant, we copy the resources from the parent into the portlet directory and then do a normal portlet build. The only caveat is that the clean target should clean out all the copied files but leave the portlet specific files.

          The component-showcase is complete for both Maven and Ant. We are now working on converting the other relevant examples that have portlet builds.

          Show
          Deryk Sinotte added a comment - To better support Maven, we decided on a strategy of having separate project directories for portlet examples rather than simply injecting the few portlet files we have into the existing servlet examples. So the new layout for examples that have a corresponding portlet build should look like: sample/ace/showcase sample/ace/showcase-portlet sample/compat/component-showcase sample/compat/component-showcase-portlet sample/core/chat sample/core/chat-portlet Inside each directory will be a build.xml and a pom.xml, with common build info factored out to the appropriate level (e.g. common to all samples, common to all portlets, common to compat, or specific to that example). Moving stuff around this way necessitates an overhaul of the ant scripts for building the portlets since they are no longer simply injecting a few files into the existing non-portlet.war. For Maven, the build-helper-maven-plugin is used in the portlet poms to allow pointing at multiple source directories so that the portlet build can simply refer to the source in the servlet folder. For Ant, we copy the resources from the parent into the portlet directory and then do a normal portlet build. The only caveat is that the clean target should clean out all the copied files but leave the portlet specific files. The component-showcase is complete for both Maven and Ant. We are now working on converting the other relevant examples that have portlet builds.
          Hide
          Deryk Sinotte added a comment -

          The work to convert the 3 portlet examples into their own projects and provide Maven and Ant builds for them is complete. The only two caveats to note:

          1) There is currently no code to filter which portlet-specific configuration files get included into the .war file. So liferay*.xml files are currently included in Pluto builds for example. While not harmful, it may be desired to clean this up.

          2) The two build systems use 2 different strategies which can collide. Maven builds by simply referring to the servlet project to get it's resources. Ant actively copies over the content it requires into the portlet directory before building. If you run an Ant build (which copies the resources) and then do a "mvn package", the build will complain that there are duplicates of the Java classes. You must do "ant clean" to remove these copies if you want to successfully do a Maven build.

          Show
          Deryk Sinotte added a comment - The work to convert the 3 portlet examples into their own projects and provide Maven and Ant builds for them is complete. The only two caveats to note: 1) There is currently no code to filter which portlet-specific configuration files get included into the .war file. So liferay*.xml files are currently included in Pluto builds for example. While not harmful, it may be desired to clean this up. 2) The two build systems use 2 different strategies which can collide. Maven builds by simply referring to the servlet project to get it's resources. Ant actively copies over the content it requires into the portlet directory before building. If you run an Ant build (which copies the resources) and then do a "mvn package", the build will complain that there are duplicates of the Java classes. You must do "ant clean" to remove these copies if you want to successfully do a Maven build.
          Hide
          Deryk Sinotte added a comment -

          I should also note that the poms for the portlet builds are not as factored as they might be (using parent pom to factor out commonality).

          Show
          Deryk Sinotte added a comment - I should also note that the poms for the portlet builds are not as factored as they might be (using parent pom to factor out commonality).

            People

            • Assignee:
              Deryk Sinotte
              Reporter:
              Deryk Sinotte
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: