First subproject of blueMarine mavenized
When I started the mavenization of my projects, in July, I really didn't
figure out that it would have been such a painful and long process. It
is literally consuming me - also because I'm longing to see the end of
the conversion, so I can resume the development.
The first mavenized projects, href="http://betterbeansbinding.kenai.com">BetterBeansBinding,
were reasonably easy, also considering that I had to learn at the same
time Maven under the surface. But they were plain JSE projects, with
just a handful of modules. blueMarine
has got hundreds of modules partitioned in 7 projects and even though I
wrote some scripts and tools to automatically generate the pom files,
they are needing tons of manual fixing.
So you can imagine my enthusiasm when, last night, the first subproject
of blueMarine (Metadata) at last compiled correctly using only Maven,
so I could drop all the Ant artifacts. Hopefully the second subproject
should be converted in the weekend, so I'll be able to start blogging
about this topic: mavenizing a NetBeans Platform project opens a number
of issues, from the management of dependencies (e.g. transitive vs non
transitive dependencies) to the lifecycle of versions.
As a first comparison, I've benchmarked how long it takes to build the
project (in my href="http://weblogs.java.net/blog/fabriziogiudici/archive/2009/09/18/repository-cohesion-another-plus-mercurial">optimized
clean status (no platform, no build artifacts)
existing platform (no build artifacts)
You can get the source code with style="font-family: monospace;">hg clone
https://kenai.com/hg/bluemarine~metadata-src and use
revision d52dc0fff7d3 for benchmarking Maven and 79f2f26dfbe7
for benchmarking Ant. Of course all the tests have been performed with all the needed files already on the disk, so there were no network downloads involved.
As expected, Maven is a clear loser here, with roughly a 3.5x factor in
build times. Part of the problem is due to the unflexible nature of
Maven: for instance, an install
always rebuilds the platform from the nbm artifacts in the local
repository, while my Ant scripts were smarter and performed a check to
execute that operation only when needed. Another obvious point looking
at the console is that, in spite of tests being disabled, Maven still
runs Cobertura, which instruments the code before realizing that there
are no tests to run. It's the usual Maven dumbness.
Hopefully, there is some room for improvements here, for instance by
using profiles and disabling some plugins when they aren't needed.
Matter for the next post.