Versions Compared

Key

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

...

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 Sonotype Sonatype m2e plug-in for Eclipse - mostly because I despise editing XML files. Getting started was not easy. While the Sonotype 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.

...

  • 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.
  • Sonotype 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 Sonotype 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 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 the 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:

...

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

...