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.

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.

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:$

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

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

• 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.

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.

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.