On 8/30/06, Russ Tremain <[EMAIL PROTECTED]> wrote:
I am a proponent of Maven 2.
[del]
So bottom line is: Maven 2 solves the dependency problem,
and works now, even for complex projects. The rest of the maven
strong points (standard build lifecycle, standard source layout, etc.)
are helpful, but in my opinion, the ability to look at a single XML file,
and document all the external dependencies of the build system I'm creating,
along with
the ability to publish artifacts in a standard way, will ultimately carry
the day.
Now, here's the trick: ant is the escape hatch. If you can't yet
do it with maven 2, you can do it with ant. We still have a lot
of ant code [1]. Some because a plugin was broken or lacking features,
(the surefire and jar plugins were particular problems), some because we
simply didn't have time to convert a set of working ant scripts, and some
because we are waiting for a plugin to mature, so we can switch (jaxb comes to
mind).
I'll agree with Russ.
I found I was heading towards a cut-n-paste ant file where I only had
to configure a few project specific settings. But it was something I
had to maintain and extend when the project started using new
features.
With Maven's convention over configuration, all that cut-n-paste has
gone and I am left declaring what I want built and not how it gets
built.
Our project is an Eclipse Rich Client in a mobile car environment,
connecting over a wireless network to our JavaEE middle tier which
then goes off to our enterprise tier.
It's not trivial but it is also not terribly complicated.
It took me quite a while to read up on how to get maven to do stuff,
but any technology has a learning curve and as previously stated in
other topics that the learning curve is quite low if you just want the
basic compile, build jar life cycle. When you start adding reporting,
other plugins like checkstyle, and assembling builds the learning
curve goes way up but it is not unmanageable. And for the most part
the existing Maven plugins do everything I want (with only some minor
bugs which were not difficult to provide patches for).
It has taken me between two to three months elapsed time (and maybe
about two months of solid effort) to get the build to this state by
building on a simple pom life cycle and slowly adding the pieces that
I needed to improve my build. Having gone through this learning curve
I can jump start future projects by taking the parent pom's contents
and pasting it into a new project (at some stage I might consider
refactoring this into a common parent pom).
Would I have been better of with Ant? I don't think so, I especially
like that I have a local repository of jars that can be shared across
projects and that my internally developed projects can depend upon
each others binary builds with known versions instead of having to
build those projects from source. For most of our developers it means
they only need the subset of modules they are working on and not the
whole project.
The only thing I have to sort out is how to get Maven to build Eclipse
plugins, and this is bleeding edge stuff that a number of people on
the list are starting to look at in earnest.
And as Russ points out, I have a workaround because I can use Ant until then.
Yes the documentation could use some more work (which is now
happening), but I usually find that a Nabble search of the dev or user
list after much reading finds me the answer I want and if necessary I
update the user wiki or provide documentation patches back. I wish
more users did the same.
All in all I have been very impressed with what I have been able to do
with Maven and I am left with a much more manageable build system as a
result.
Bae
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
