So far we have covered all the work we have done setting up Maven:
- The requirements for our Maven process.
- The infrastructure we have set up.
- The project configuration details.
As I went along, I also described some of the reasons for each part and some benefits. However, all of the work above does not guarantee that our process works smoothly every time. We do hit problems every now and again. Here, Samuel Le Berrigaud, James Dumay and I share some of the most frequent and some of the most sore issues we have to deal with from time to time.
Maven users need training.
We believe this is the most important and most overlooked issue of all.
One problem is if you are migrating projects from Ant or Maven 1 to Maven 2. Your developers used to know their build system very well and all of a sudden they lose control.
Another issue is when the problems occur – developers with little Maven exposure find it difficult to understand what is going on and how to fix it. Maven concepts need to be understood in order to deal with their issues.
Yet another issue is that Maven 2 comes with some very different concepts from either Ant or Maven 1. Some of those differences are lifecycle, working with Maven plugins and the dependency management for example. Those have to be explained carefully to the users. Otherwise your team of Maven “experts” will spend their time answering the same basic Maven 2 questions multiple times a day.
Here at Atlassian we started our Maven training sessions. The goal is to explain Maven philosophy and concepts, provide how-tos for most of the daily tasks and do away with some of the the myths. So far the training sessions are turning out to be successful.
Check your settings.xml
This is something we had to say a lot to our developers. As it was described in Part 2 of these series we have a few repositories – internal and external – that, combined with the proxies, we use to download from and deploy artifacts to. We also said that in order to benefit from this infrastructure developers must configure their Maven environment correctly and that we have a pre-configured settings.xml file available. The overwhelming majority of the cases when someone comes to us with: Maven can’t find my artifact or I get authentication issue when deploying my artifact get resolved by making sure their settings.xml is correct.
IDE integration
The declarative nature of Maven allows for better integration with IDEs than other tools like ANT. This is true for Maven 1 and remains the same for Maven 2.
So for our developers running mvn idea:idea or mvn eclipse:eclipse at the root of their project should setup their development environment. It works well for most smaller projects and projects where Maven conventions are followed. However some teams have very complicated project structures where those plugins don’t really do a good job. Having the possibility of setting up a development environment in the minimum amount of time is really a strong point in favour of Maven 2. However it seems that we will need to do more work on some projects to get them to the level of just using one command line for that.
IDEs are now coming with integrated Maven support as well. But they all have the same shortcomings as the Maven plugins and we won’t be able to it use in all our projects. The best Maven support we have seen so far is definitely the one in Netbeans. IntelliJ IDEA has some good support as well but not quite to the level of Netbeans. As usual with Eclipse there are several plugins to choose from but none of them is quite as good as NetBeans.
Profiles
Build profiles are are a great idea. A lot of times profiles are used where they shouldn’t be. This, unfortunately, makes us think that profiles are evil.
Profiles are useful when something needs to be activated seamlessly depending on user environment (JDK, OS, etc.). This seems reasonable. Another use of profiles is changing the database or an application server that you are going to be using to run your functional tests. Activating the profile on the command line makes sense here. But one needs to be able to run the same tests with a default environment out of the box without activating any profiles.
It is wrong to use a profile to activate the module which is responsible to functional testing. Such setup is tempting for it takes a long time to run functional tests and you might not want to be running them every time you run Maven. The problem, however, is that if you are going to do a release you have to remember to include this module by activating the profile. Very often this is forgotten.
Use of profiles is also not obvious unless you are intimately familiar with this projects setup. Therefore, when you try to run a Maven goal and it fails you are thinking that Maven is broken and get frustrated whereas you simply didn’t invoke the right profile.
Group Id change
Each maven project (artifact) is uniquely defined by its group id and artifact id. Arguably the version is also part of the identifier.
Between Maven 1 and Maven 2 the conventions for group ids have changed. The convention (if it was a convention) in Maven 1 was to use the same value as the artifact id. However in Maven 2 group id looked more likes package name. For example if you take Atlassian Seraph its groupId:artifactId was atlassian-seraph:atlassian-seraph in Maven 1 and we changed for com.atlassian.seraph:atlassian-seraph in Maven 2.
This had a serious impact on projects that depend on this library. The greatest impact was when dealing with dependency management. As far as Maven 2 is concerned atlassian-seraph:atlassian-seraph and com.atlassian.seraph:atlassian-seraph represent two different libraries. This made it easy to end up with one of each on the classpath of the project.
This is not something your developers are going to enjoy. This is especially true because when you exclude the dependency from somewhere, it has the tendency of coming back from somewhere else. This will still be the case until someone fixes MNG-1977.
We migrated the group ids of almost all of our libraries pretty much at the same time. The more libraries you migrate – the worse the issue gets. Our first advice is to do it one library at the time. And don’t start migrating it until you have all your project up to date with their dependencies – i.e. using the latest stable version.
Here is another issue with group ids. When the we took over the maven-clover-plugin code from the apache community it was decided to change the group id from org.apache.maven.plugins to com.atlassian.maven.plugins. While this seemed like a good idea it caused its own share of issues.
The biggest issue here is that if one is currently using the clover plugin on the command line, Maven will be using the old version of the plugin. This is true even if you define the Atlassian pluginGroup in your settings.xml or the exact plugin to use in the pluginManagement section of your POM. If you want to make it work you would have to use either the plugins section of your POM or the long command line as per mvn com.atlassian.maven.plugins:maven-clover-plugin::clover. We hope to fix this issue soon though.
Archiva issues
Out of all the proxy servers we have picked Archiva because it matched our requirements the most. However, when we started using it — it wasn’t even version 1.0. We have discovered a lot of issues with it and Archiva guys so far have been very quick to address them. James Dumay also has adopted Archiva and has been contributing back to the project. It is slowly shaping up to be what we want in terms of stability, performance and even feature-wise. However, since it is a single most important part of our infrastructure, every time something goes wrong with it, everyone is affected.
Summary
These are some of the issues we have remaining with our Maven setup. On the grey side – they still cause some irritation for everyone. On the bright side, they are becoming less and less frequent.
We believe that after everyone had been properly introduced to Maven through our training sessions they will feel more confident dealing with Maven.
We also think that now we are dealing with issues that are related to our usage of Maven rather than Maven variables that we had no control over.
On the other hand — we would love to know what is your Maven experience like. What issues are you dealing with? What problems have you solved with Maven and in what way?
Since after the previous part we received some very valid comments about using Maven for our releases, we decided to write up another entry dedicated to the subject. It will be posted in the next week or two so stay tuned for more Maven lovin’ and goodness!