Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.0.0.BETA, 3.1.0.BETA1
    • Fix Version/s: 3.1
    • Component/s: Release
    • Labels:
      None
    • Environment:
      All
    • Assignee Priority:
      P2
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial, Compatibility/Configuration

      Description

      There are a number of various tickets open for making changes and improvements to the Maven builds. Creating this as the parent JIRA for those others.

        Issue Links

          Activity

          Hide
          Deryk Sinotte added a comment -

          I've done some significant refactoring of the Maven pom files for all the samples as part of an effort to close a number of the related JIRAs and make it easier to change the bundle for EE releases.

          I've pulled up various libraries into dependencyManagement and profiles sections.
          I've parameters relevant names and versions so that they can be changed in one spot.

          I've added the following property in the top parent pom:

          <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

          to get rid of the dreaded:

          "[WARNING] Using platform encoding (xxxxx actually) to copy filtered resources, i.e. build is platform dependent!"

          I don't think this should cause an issue but it's easy to remove if it does.

          • It looks like our Ant and Maven builds aren't consistent with the libraries they end up putting in. I haven't correct this yet as things were compiling fine but they should probably be made to be consistent if possible. At least for compat, it looks like Ant likes to include commons-collections.jar and jstl.jar over and above what the Maven builds include.

          [deryk] auctionMonitor > ant; ls build/dist/exploded/WEB-INF/lib/
          commons-beanutils.jar
          commons-collections.jar
          commons-logging.jar
          icefaces-compat.jar
          icefaces.jar
          icepush.jar
          javax.faces.jar
          jstl.jar

          [deryk] auctionMonitor > mvn package; ls target/auctionMonitor/WEB-INF/lib
          commons-beanutils-1.8.0.jar
          commons-logging-1.1.jar
          icefaces-3.0.1.jar
          icefaces-compat-3.0.1.jar
          icepush-3.0.1.jar
          javax.faces-2.1.6.jar

          [deryk] component-showcase > ant -q clean servlet-profile; ls -1 build/dist/exploded/WEB-INF/lib/

          commons-beanutils.jar
          commons-collections.jar
          commons-logging.jar
          icefaces-compat.jar
          icefaces.jar
          icepush.jar
          javax.faces.jar
          jstl.jar
          jxl.jar
          krysalis-jCharts-1.0.0-alpha-1.jar

          [deryk] component-showcase > mvn -q clean package; ls -1 target/component-showcase/WEB-INF/lib

          commons-beanutils-1.8.0.jar
          commons-logging-1.1.jar
          icefaces-3.0.1.jar
          icefaces-compat-3.0.1.jar
          icepush-3.0.1.jar
          javax.faces-2.1.6.jar
          jxl-2.6.8.jar
          krysalis-jCharts-1.0.0-alpha-1.jar

          One thing that gets changed as part of the EE build is the groupId in the child poms that refers to the parent pom. This will still need to be done manually as you can't use properties in the parent section. So we'll need to batch replace:

          <groupId>org.icefaces.samples</groupId>
          with:
          <groupId>com.icesoft.icefaces-ee.samples</groupId>

          To be honest, I don't think the parent/child pom relationship should actually require changing for EE releases but that's what we have for the moment.

          Show
          Deryk Sinotte added a comment - I've done some significant refactoring of the Maven pom files for all the samples as part of an effort to close a number of the related JIRAs and make it easier to change the bundle for EE releases. I've pulled up various libraries into dependencyManagement and profiles sections. I've parameters relevant names and versions so that they can be changed in one spot. I've added the following property in the top parent pom: <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> to get rid of the dreaded: " [WARNING] Using platform encoding (xxxxx actually) to copy filtered resources, i.e. build is platform dependent!" I don't think this should cause an issue but it's easy to remove if it does. • It looks like our Ant and Maven builds aren't consistent with the libraries they end up putting in. I haven't correct this yet as things were compiling fine but they should probably be made to be consistent if possible. At least for compat, it looks like Ant likes to include commons-collections.jar and jstl.jar over and above what the Maven builds include. [deryk] auctionMonitor > ant; ls build/dist/exploded/WEB-INF/lib/ commons-beanutils.jar commons-collections.jar commons-logging.jar icefaces-compat.jar icefaces.jar icepush.jar javax.faces.jar jstl.jar [deryk] auctionMonitor > mvn package; ls target/auctionMonitor/WEB-INF/lib commons-beanutils-1.8.0.jar commons-logging-1.1.jar icefaces-3.0.1.jar icefaces-compat-3.0.1.jar icepush-3.0.1.jar javax.faces-2.1.6.jar [deryk] component-showcase > ant -q clean servlet-profile; ls -1 build/dist/exploded/WEB-INF/lib/ commons-beanutils.jar commons-collections.jar commons-logging.jar icefaces-compat.jar icefaces.jar icepush.jar javax.faces.jar jstl.jar jxl.jar krysalis-jCharts-1.0.0-alpha-1.jar [deryk] component-showcase > mvn -q clean package; ls -1 target/component-showcase/WEB-INF/lib commons-beanutils-1.8.0.jar commons-logging-1.1.jar icefaces-3.0.1.jar icefaces-compat-3.0.1.jar icepush-3.0.1.jar javax.faces-2.1.6.jar jxl-2.6.8.jar krysalis-jCharts-1.0.0-alpha-1.jar One thing that gets changed as part of the EE build is the groupId in the child poms that refers to the parent pom. This will still need to be done manually as you can't use properties in the parent section. So we'll need to batch replace: <groupId>org.icefaces.samples</groupId> with: <groupId>com.icesoft.icefaces-ee.samples</groupId> To be honest, I don't think the parent/child pom relationship should actually require changing for EE releases but that's what we have for the moment.
          Hide
          Deryk Sinotte added a comment -

          The JSF implementation (Mojarra vs MyFaces) and the portlet bridge implementations are both profiles now. So the following profiles are available:

          servlet (Mojarra for servlet containers) - default for all samples
          web (Mojarra for web containers)
          servlet-myfaces (MyFaces for servlet containers)
          web-myfaces (MyFaces for web containers)

          portletfaces (the PortletFaces Bridge) - default for all portlet samples
          liferayfaces (the LiferayFaces Bridge)

          When you build all the default examples, they'll include Mojarra. Portlet examples will also include the PortletFaces Bridge. To build different targets, you can specify the profiles on the command line like so:

          [deryk] chat-portlet > mvn package -P web-myfaces,liferayfaces

          This would build the chat-portlet example using MyFaces (but not including it in the war as 'web-myfaces' assumes it's provided) and the Liferay Faces Bridge.

          Show
          Deryk Sinotte added a comment - The JSF implementation (Mojarra vs MyFaces) and the portlet bridge implementations are both profiles now. So the following profiles are available: servlet (Mojarra for servlet containers) - default for all samples web (Mojarra for web containers) servlet-myfaces (MyFaces for servlet containers) web-myfaces (MyFaces for web containers) portletfaces (the PortletFaces Bridge) - default for all portlet samples liferayfaces (the LiferayFaces Bridge) When you build all the default examples, they'll include Mojarra. Portlet examples will also include the PortletFaces Bridge. To build different targets, you can specify the profiles on the command line like so: [deryk] chat-portlet > mvn package -P web-myfaces,liferayfaces This would build the chat-portlet example using MyFaces (but not including it in the war as 'web-myfaces' assumes it's provided) and the Liferay Faces Bridge.
          Hide
          Deryk Sinotte added a comment -
          • Added poms for icepush, core, ace, compat as well as a top-level pom under trunk/icefaces which acts as the parent for everything. As a result, I've removed the trunk/icefaces/maven2 directory as it should no longer be necessary to install with Ant so that you can use Maven.
          • It should now be possible to issue "mvn clean | package | install | deploy" from the icefaces/trunk or from any of the core directories and have the proper Maven behaviour applied. Issuing "install" should install everything to the local repository. Issuing "deploy" should install as well as create a deployable recreation our own Maven site on the local filesystem for testing and copying. This is currently located at file://$ {user.home}

            /icefaces/local-test-repo

          • Since icepush is just a staged .jar file, there is currently no way to provide jars for sources and javadocs yet. I've create a pom in the actual icepush part of the repository so if/when we decide to pull it in, it should be relatively easy to integrate with the Maven poms we already have in the icefaces section. For now it just installs and deploys the .jar file that's already there.
          • The samples directories have been tweaked to share the same top-level parent pom to ensure properties are consistent for all child poms. Issuing "mvn package" should result in a .war file with the same set of dependencies as the ant builds generate.
          • We aren't in a position to do everything with Maven yet as there's issues with the layouts not being Maven friendly, things like the component generators needign to run, and the ProductInfo files needing preprocessing. So at this point, core, ace, can compat still call Ant targets during Maven to generate the required jars, javadocs, etc. and then the artifacts are post-processed by other Maven plugins.
          • I was finally able to get this plugin to work:

          <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-release-plugin</artifactId>
          <version>2.2.2</version>
          </plugin>

          so that you can try to easily update all the versions of the parent and child pom files. Right now there seems to be a bug in the newer versions of the plugin (ie 2.3.x) where it just silenty fails but reported that it succeeded. So I tried the 2.2.x version but that only seems to work on revisions with the "-SNAPSHOT" suffix.

          Here's what I used to get it to update all the modules, fired from the top of the project:

          mvn --batch-mode release:update-versions -DdevelopmentVersion=3.1.0-SNAPSHOT

          There are more advanced "release" style plugins that do this for you and more but we're not quite there yet.

          Show
          Deryk Sinotte added a comment - Added poms for icepush, core, ace, compat as well as a top-level pom under trunk/icefaces which acts as the parent for everything. As a result, I've removed the trunk/icefaces/maven2 directory as it should no longer be necessary to install with Ant so that you can use Maven. It should now be possible to issue "mvn clean | package | install | deploy" from the icefaces/trunk or from any of the core directories and have the proper Maven behaviour applied. Issuing "install" should install everything to the local repository. Issuing "deploy" should install as well as create a deployable recreation our own Maven site on the local filesystem for testing and copying. This is currently located at file://$ {user.home} /icefaces/local-test-repo Since icepush is just a staged .jar file, there is currently no way to provide jars for sources and javadocs yet. I've create a pom in the actual icepush part of the repository so if/when we decide to pull it in, it should be relatively easy to integrate with the Maven poms we already have in the icefaces section. For now it just installs and deploys the .jar file that's already there. The samples directories have been tweaked to share the same top-level parent pom to ensure properties are consistent for all child poms. Issuing "mvn package" should result in a .war file with the same set of dependencies as the ant builds generate. We aren't in a position to do everything with Maven yet as there's issues with the layouts not being Maven friendly, things like the component generators needign to run, and the ProductInfo files needing preprocessing. So at this point, core, ace, can compat still call Ant targets during Maven to generate the required jars, javadocs, etc. and then the artifacts are post-processed by other Maven plugins. I was finally able to get this plugin to work: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <version>2.2.2</version> </plugin> so that you can try to easily update all the versions of the parent and child pom files. Right now there seems to be a bug in the newer versions of the plugin (ie 2.3.x) where it just silenty fails but reported that it succeeded. So I tried the 2.2.x version but that only seems to work on revisions with the "-SNAPSHOT" suffix. Here's what I used to get it to update all the modules, fired from the top of the project: mvn --batch-mode release:update-versions -DdevelopmentVersion=3.1.0-SNAPSHOT There are more advanced "release" style plugins that do this for you and more but we're not quite there yet.
          Hide
          Deryk Sinotte added a comment -

          Tested and checked in all the poms. Resolving as fixed.

          Show
          Deryk Sinotte added a comment - Tested and checked in all the poms. Resolving as fixed.
          Hide
          Deryk Sinotte added a comment -

          Fixed some issues:

          • switching the Mojarra version to be our patched version <mojarra.version>2.1.10-ice-8156</mojarra.version>
          • ensure that the bridge.js files are included in the icefaces.jar as they are dynamically generated during the build
          • ensure source code is included in the showcase.war so that the source code feature works
          • update the ReadMe file to remove the reference to the maven2 directory as it was removed (linked JIRA ICE-8343)

          Made some changes to support Maven 3 which is stricter about pom.xml verfication and issues a number of warnings:

          • add plugin versions
          • ensure project related expression include the project prefix

          The only one we can't really do anything about at the moment is:

          [WARNING] 'artifactId' contains an expression but should be a constant. @ org.icefaces:$

          {icefaces.lib.name}

          :3.1.0-RC1-SNAPSHOT, /Users/deryk/Repo/svn/ossrepo/icefaces3/trunk/icefaces/core/pom.xml, line 30, column 17

          Show
          Deryk Sinotte added a comment - Fixed some issues: switching the Mojarra version to be our patched version <mojarra.version>2.1.10-ice-8156</mojarra.version> ensure that the bridge.js files are included in the icefaces.jar as they are dynamically generated during the build ensure source code is included in the showcase.war so that the source code feature works update the ReadMe file to remove the reference to the maven2 directory as it was removed (linked JIRA ICE-8343 ) Made some changes to support Maven 3 which is stricter about pom.xml verfication and issues a number of warnings: add plugin versions ensure project related expression include the project prefix The only one we can't really do anything about at the moment is: [WARNING] 'artifactId' contains an expression but should be a constant. @ org.icefaces:$ {icefaces.lib.name} :3.1.0-RC1-SNAPSHOT, /Users/deryk/Repo/svn/ossrepo/icefaces3/trunk/icefaces/core/pom.xml, line 30, column 17
          Hide
          Deryk Sinotte added a comment -

          Added a pom to the icepush/trunk/icepush portion of the repo that uses icefaces3/trunk/icefaces/pom.xml as it's relative parent (meaning it relies on it being the same relative location as layed out in the current repo). This pom will deploy source and javadoc jars to the same location as the rest of the icefaces artifacts.

          Show
          Deryk Sinotte added a comment - Added a pom to the icepush/trunk/icepush portion of the repo that uses icefaces3/trunk/icefaces/pom.xml as it's relative parent (meaning it relies on it being the same relative location as layed out in the current repo). This pom will deploy source and javadoc jars to the same location as the rest of the icefaces artifacts.
          Hide
          Deryk Sinotte added a comment -

          I believe the the bulk of the work has been completed for this so resolving as fixed. Any specific future issues should be resolved under their own specific JIRAs.

          Show
          Deryk Sinotte added a comment - I believe the the bulk of the work has been completed for this so resolving as fixed. Any specific future issues should be resolved under their own specific JIRAs.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: