Pushing Maven to Work

Addendum (See here: Leaving Maven)

I think there's no doubt, that people trying to get started with Maven encounter three experiences:

• They're struggling with the first examples.
• They're amazed if they realize the possible power of this tool.
• They stumble across so many difficulties with the management of dependencies, that a big amount of beginners starts to hate it.

That's sad!

In fact, Maven, as long as it works, is a very powerful and sophisticated tool. So, I personally keep on struggling, since in the long term it seems to be a profitable alternative. This holds for me for the following items:

• Customizable project templating
• Manage dependencies for a whole team
• Well defined delivery artifacts like jars, reports, etc.
• Large community
• Extensability

So I decided to gather some useful information at this place, that I had while struggling...

So, here are the tips

1. If Maven is unable to download a dependency, download the source and install it in your local repository. So for example for a subversion repository of an imagined plugin ketchup:
   • svn co KETCHUP_REPOSITORY_URL
   • cd ketchup
   • mvn [-U] install
   The -U switch enables Maven to download updates for the case of missing updates. This once helped me to fix a dependency.

   After you have done this, try to build your project. For me this worked fine until now.

2. This is an easy one: Are you wondering why changes to your code are not properly used by the build? If you run

   mvn test

   for example? Did you run

   mvn clean

   first? There it is! Maven uses possibly still classes, you have renamed or deleted since the compiled artifacts still exist! So do it this way:

   mvn clean test

This list has few entries for now. But I'll keep it updated if I find out new helping hints that could be useful to share.

How could Maven be done right?

Up until now, I struggled and tried to cope with Maven for several times. Unfortunately only the 'getting-started-experience' was cool. The major goal of Maven is to facilitate the management of software projects for the development team in order to enable them to focus on problems---and not on development environment maintenance. This does not hold for me. The Maven struggle is a real time waster. But no doubt: I'd love to have such a tool. The latter arises the question, what is needed to increase the usability.

Identifying the main issues

In my opinion there are three major issues:

The Maven main repository and the missing connections of external plug-in contributors to it.

It's basically a nice idea to have information provided at a central place. But in the case of Maven this does not seem to work. Even if you manage to cope with dependency issues primarily, it is not said that plug-in providers keep their newest builds in sync with their Maven versions.

Fragmentation of configuration

In the Java world, configuration is---potentially---a mess. In earlier days, configuration was done mainly with xml deployment descriptors. Many people encountered maintenance issues with those, so since Java 5 there is the possibility to use annotations instead. By now, there are people already speaking of annotation spam. It's getting even worse with the combination of both. And now: Add Maven to it! There is the pom.xml. Inside it, you specify settings at different places. A plug-in dependency is in the dependencies section, while build settings for the same plug-in are set in the build section. This is seperation of concerns at the wrong place in my opinion. But the worst thing related to this I came over was the ability of the pax-exam osgi test suite. It added a third possibility to configure itself by writing Java code. Who needs this? Why? This is not only a maintenance nightmare. This already a project setup nightmare. Can you say that? ;-)

Plug-in wrappers hide underlying functionality

The trend to mavenize all your project related tools leads straight forward to hidden functionality of those. This may be a common problem for overused build tools, since you may have that for example with Ruby's Rake too (Try using Cucumber with Rake: You may call it in Rake-enabled projects indirectly by calling rake features. If you now try using a different spoken language in your feature files, it will not work out of the box, because Rake will not pass through command line options.) I had this by using the combination of Grails and Maven. Just try it by yourself: Initialize a Grails project, install a Grails plug-in and try to invoke it's generators through the Maven wrapper. It won't work.