Maven

April 14th, 2004 by Hen

I’m firmly in the liking Maven camp.

Dependency grabbing is a first big win for me. We need a CJAN and Maven is bizarrely the first real thing that enough people use to make such a thing happen. Creating my own repository of jars would be a pain in the arse. I have been tempted at work to stop people hitting the iBiblio repository and only use an internal one if we decided to control what jars were legal to use.

I hate building things with Ant. I’ll type ‘ant’ and it will fall over. I’ll look and discover I have to edit build.properties and find jars for it, downloading from god knows where and finally get it all patched together so the Ant file will build.

Either that or I’m downloading lots of Jars in the distribution or getting them out of CVS. The CVS case seems to implicitly have the Hibernate problem. I get ‘commons-lang.jar’ and not ‘commons-lang-1.0.1.jar’. ie) The project hides the dependency version.

I have two major environments in which I use Maven as an admin. Work and OSJava. I’ve customised things increasingly in both places. The OSJava stuff has been customised a lot on the website side [due to Hani’s complaints actually] and no longer uses the Maven menu which I dislike. Having now found what I like there, I could dump Maven and create a global Ant system to replace it, but why bother. I’d only have to design the website and match the features I use.

The Work stuff is good, because it stops every developer there having to constantly hack Ant scripts. At an early point someone was doing lots of custom jelly things in the maven.xml, but I’m slowly weeding this out. My belief is that maven.xml should rarely exist. For the things that have a need to exist, I have created a work-plugin which effectively becomes the standard extra functionality. Mainly it lets me manage all of the companies build system a lot more easily than if there were a plethora of Ant scripts out there.

As you asked, my problems with Maven, and I’ve suffered with it since 0.1:

Dependencies of dependencies are not solved. Someone seems to have tried to fix this very early on as they used to have pom/ folders on the first Maven repo, but they were never filled. It seems quite simple and recursive a thing to do. JJAR was closer to this the day Maven was born than Maven seems to be. [JJAR was Geir Magnusson’s dependency handler that is in Jakarta Commons Sandbox and became obsolete and died when Maven emerged. It could be called from Ant and give people their dependency system].

No concept of dependencies having different needs. Ones that should be packaged for runtime in the dist, unit-test only ones, etc. Again, 0.1->0.4 used to have a comment saying it had to separate runtime and compile time ones. I think that came from Maven and not me. It seems to be an issue that has dropped out now so I have to do my own true property.

Changing website between rc1 and rc2. I like having a simple, easy to use documentation system. It’s not beautiful, but it’s better than what I’d create with the time I can devote. I’ve tweaked the colours a bit, made my own navigation.xml etc. However in rc2, people are raining on my parade with a changed site. I need to see if I can set some property to old.site=true, but I doubt it. This will keep me on rc1 indefinitely as I’m not suddenly changing my l&f at another project’s insistence.

Jelly. I’m okay with Jelly. Yes it’s a bit odd, but for basic needs, one language is much the same as another. The biggest problem with Jelly is that it’s not a very active project. I can deal with the brackets if must be, but Maven are right to get off of Jelly as they are the only real users I’m aware of.

Documentation. It’s better than it used to be, but not as good as it once was. Maven 0.4 or so had good docs. Pete Kazmier did some good work here, but as I think happens to a lot of documentors, found himself more and more involved in product development than product documentation. Then it got really bad. The site documented CVS HEAD and this was horribly out of touch with the latest stable release. Then it got better as the site and stable got closer to each other due to less releases. Now it seems quite unchanging. Things like Wiki’s can help here, but in Maven’s case, and many others, I think it merely adds to a greater confusion as there are more locations to find the information in. Unmanaged.

Arrogance. Maven advertising contain(s?)(ed?) a lot of arrogance. Take the automatic ‘Development Process’ which is put on the end of every navigation list. Hooking everyone up to claim they use Maven’s processes. The site should be very empty by default and require active turning on of things. It’s easy to add a line to add Javadoc report generation, it can be a pain to figure out how to hack it out. Make the default Maven site/functionality simpler.

Too late to keep going on. I should just blog this separately :)

Comments are closed.