Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


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.


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:


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


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.


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.


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