I've been using Maven for about 6 months now, and more recently I have been trying to integrate it into our team software development environment for production use. This is a starting place to reflect on the process and make a few notes to other who attempt this too.


About October 2010 I began to formulate a new architecture to replace some of our legacy product infrastructure.By December there seemed to be enough buy-in from the rest of the team to take things seriously and do some serious technical investigation. Our manager decided that if we were going to do this then we would have to make a decision by the end of January 2011 on how to proceed. I spent most of January implementing technology proof of concept experiments to support my architectural choice.

Along the way I had to rapidly learn a lot of new technologies I had no real experience with. One of the most memorable was Hibernate, because it was so excessively difficult to do the most simple basic things. I used Google to search for some good "getting started" examples, but most of the example were atrocious, and the few good example there were all required you use Maven. I really had no idea what Maven was, I had only heard the term a few times, but it really pissed me off having to learn a whole new technology before I could simply write "Hello World" in Hibernate. Eventually I figured out on my own how to write a simple "Hello World" program in Hibernate, but it is still sad I could find no such examples via Google.

Eventually January was over and the team settled on my proposal and I had to take proof of concept code to the next level - proof of technology. I always promised myself I would investigate Maven further because every where I search it kept popping up and people kept raving about how wonderful it was. I settled into actually beginning a completely new project with Maven and started with the Sonatype m2e plug-in for Eclipse - mostly because I despise editing XML files. Getting started was not easy. While the Sonatype manuals for Maven and Eclipse appeared well written it turned out they were more pretty than useful - but they were still enormously better than anything else I found. I was able to get started fairly quickly with Maven, but it was incredibly stressful.

Astronaut's View

After actively using Maven, and associated technology, for about 6 months I have come to the following conclusions:

OK, if you are squeamish about criticism of Maven - stop reading now. Click the back button on your browser and move on and never come back. You have been warned!

When I first started turning proof of concept into proof of technology I tried using the IBM Rational Jazz set of tools. To be clear, these tools are incredibly well designed by a team of experts who really grok software development methodology - but they are kind of pricy. In the end I simply ran out of resources trying this new technology and had to switch to 'plan B' which was our existing set of tools.

Maven, Eclipse, Nexus, Perforce, Team City, Oh My!

This part is so under construction right now - just bear with me.

Currently I am using Eclipse Java Indigo, with the beta release of m2e for Indigo, and Nexus running on VMWare.


When I first started using Perforce I thought it was the greatest thing since CVS. After using Jazz, I am so disillusioned with Perforce now. Anyway...

Perforce requires that you root everything. Unlike Jazz where you can put your (Eclipse Workspace)/(Jazz Sandbox) anywhere.

While many parts of Eclipse work off of relative file system paths, there are still too many things, like m2e (where some developers have no idea what relative means) that force you to use absolute file system paths. Also, many other Maven configuration things do not work well off of relative paths. You have to take this into account. The approach I chose to use, and sadly only for Microsoft Windows, was to require everyone create at P: drive on their workstation. This is most easily accomplished by creating a perforce.cmd file with the following contents:

mkdir %USERPROFILE%\Perforce
subst p: %USERPROFILE%\Perforce

and putting this in the C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup folder. This sets a standard that you can use in other configuration files. If someone has different workstation configuration, they can change this and put it in either

For example, put the following in C:\Users\myId\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup, or wherever the right place is in that version of Windows :

mkdir D:\someplace\Perforce
subst p: D:\someplace\Perforce

The point is that when you create your Peforce workspace everyone needs to make the root be P:

This kind of screws anyone who wants to work from OS X or Linux, but I am forced to use Windows under protest, and my imagination does not go any further at the moment.


Now that you have a standard place for your Perforce workspace on the local file system, it makes configuring absolute paths so much easier.

I recommend everyone stick with the Perforce workspace naming convention user_hostname, for example


or something similar, especially if you like to develop code from several places - like at work and at home :-)

Now you can create an Eclipse workspace (workbench) like P:\supercool that is in harmony with Perforce, and everything flows from there.


This is the part where you have to give up on tradition.

You have to put your user and global Maven stuff somewhere other than the standard places. This is the convention I chose:


Now. in Eclipse you have to make P:\supercool\Maven and Eclipse project so that it can manage things accordingly. In particular you need to do a team>share>Perforce with this directory, and then team>share>Add to.p4ignore on your P:\supercool\Maven\repository so you don't add that crap to Perforce (unless you are really that paranoid about artifacts aging out on you) :-)

Now you set preferences>Maven>Installations:Global Settings for Installations to


and preferences>Maven>User Settings:User Settings to


Now when every you need to change your Maven settings it is under Perforce control and every other developer can pick up the changes. If you don't do things this way m2e will freak out on you and resort to ~/.m2 which is not what you want.


Now that Maven, Eclipse and m2e are relatively stable you can set up Nexus...