For the past few weeks, I have been leading the migration to Maven effort for JBoss Portal.
With converting any existing ant project, it's a given to start at the top of the dependency hierarchy and in this case it is the common module. (AKA - The Tip of the Ice Berg ;-)
Below is a list of "challenges" I encountered and workarounds:
Challenge: Refactoring
Much of Maven's power comes from the standard practices it encourages. Poms are smaller, the project is easier to understand, it's easier to integrate plug-ins, and leveraging the standard directory structure will end up saving money, time, and learning curves.
Moving things around to meet the "Maven standard" only caused a few ant targets to break which were easily fixed and this will be the case with refactoring any ant build.
I used Intellij Idea 7+ (EAP) to refactor and I was disappointed to find out that I lost the svn history on a few (important) directories. This was a reported issue in 2005, but it may have been an overloaded commit on my part. I had many changes and moves going on in one commit so it may be better to commit to svn incrementally using Idea. I will do some more tests to be sure. For now, I'm using the command line.
Challenge: Ant System Properties
Another problem I ran into was the use of ant system properties in jUnit tests. Maven does not allow one to set System Properties for use in the JVM from within a pom.xml file. I also tried setting the property via the maven-ant plugin to no avail.
You can read any system property in the pom.xml (see this properties guide) but you cannot write to them via the pom. This is also discussed on the maven mail list here.
Solution
The suggested way is to pass a system property in with "mvn install -Dmyprop=whatever" on the command line.
Challenge: Placement of the pom.xml
The current structure of the svn module dictates your pom placement. There are a few factors to take into consideration when placing the poms:
- How will Eclipse, Idea, Netbeans handle placement with built in IDE integration?
- How will the automated build checkout and use the pom? In our case we use Hudson.
- How many levels of modularization do you want to maintain?
These are all questions that need to be answered and I'm sure there are a few I missed. I am a big fan of K.I.S.S (not the rock band... "Keep It Simple Stupid"). When you have a huge project like this and are dealing with different releases, modules, versions, etc... you really must understand how the poms will be used and how the artifacts need to be deployed. Starting from a basic compile with maven, getting your tests running, then deploying to the snapshots repository seems to be the best beginning. Once the base is setup we can start adding the cool reporting, property file encoding, selenium tests and other fun stuff.
This brings me to a good point for mentioning Migrating to Maven from Ant (part 2). We still have Cargo and integration tests to setup, running WARs in your container of choice and Maven profiles that will allow you to build any flavor of JBoss Portal that you may desire. I will be sure to document and blog as we move along to migrating the different parts of JBoss Portal.
To get the current Maven environment setup follow these instructions on our Wiki. If you use IntelliJ Idea (or if you want to give it a try ;-) follow the directions here for getting the common module setup. Idea will also generate and maintain Eclipse project files so you can make everyone happy!
I would also like to recognize Anders for his contributions to the migration.
