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.
After actively using Maven, and associated technology, for about 6 months I have come to the following conclusions:
- I truly understand the excitement people have over Maven. Conceptually it is an extremely innovative tool and approach to things.
- One of the things I like most is the 'convention over configuration' attitude about things. Don't give people choices and unnecessary flexibility, just encourage everyone to do the common things all the same way.
- When I read how people in the open source community faced the challenge of moving from one open source project to another, and they were all different, I could appreciate how much of a burden it was having to grok yet another software project. Maven seemed to address this problem directly.
- It would be impossible for Microsoft to conceive of such a concept because they are corporately opposed to open source.
- Because I was hard pressed to deliver a lot of promised functionality with scant resources, I had to depend on open source artifacts like we never had before. The dependance management in Maven supports this extensively well. At first it was incredibly easy to Google for solutions for problems I had and then find their Maven coordinates. However, it took me several months to grok the concept of artifact coordinates - there is no documentation that I have found that explains it clearly.
- I learned to really appreciate the life-cycle approach to things. At first it was hard not doing things procedurally in terms of Ant, and to learn to trust the more declarative style of Maven, but now I really appreciate it.
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!
- From the broadest perspective Maven is too high in functionality and too short on usability. No offense intended - but it appears to be designed by hackers for hackers.
- I am really tired of people telling to stop using m2e and just use the command line. That is so 20th Century.
- Sonatype seemed to have stepped up to the usability issues with both free and value added products. I commend them, but there is still a long way to go.
- Maven's biggest shortcoming is the enormous amount of manual configuration required. This is really an irony given the 'convention over configuration' goals Maven aspires to.
- Someone once said about Maven, if it seems hard, you are not doing it right. The problem is there is too little guidance on what doing it right means, and consequently the maven users mailing list is extremely active - but the people there are enormously eager to help.
- As my MSc thesis was related to databases I will try to put this in database terms:
- Maven, m2e, Nexus, etc., are all like an enormous database of configuration information - with no data integrity control!
- While there are diagnostic messages when things go wrong, they are for the most part abstruse.
- Basically the integrity of the configuration information is almost completely manual, and too vulnerable to normal human mistakes, and misunderstanding. Don't document it - automate it!
- Tools like m2e help offset this somewhat, but they are only a first step in the right direction.
- What Maven needs most in terms of usability, is some super cool gee-wiz configuration sanity checking wizard graphical user interface thingy. Maybe in my next career Sonatype will hire me :-)
- When you try to architect a developer environment that is high on usability and low on documentation, and you have to integrate tools like Maven, Eclipse, Nexus, Perforce and Team City - there is no road-map - so I will try to start one here.
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
- C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
- C:\Users\myId\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
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...