On 13 Oct 2010, at 8:52 PM, Leon Rosenberg wrote:
Many traditional programming languages are declarative and not
procedural or are based on declarative concepts, most of the time the
declarative nature of such languages proved itself problematic.
But seriously is there a comparison matrix somewhere which compares
ant+ivy vs maven?
A comparison would make little sense, because ant and maven aren't
alternatives for one another. Ant is a language that allows you to
create custom build scripts, but you are required to write those build
scripts yourself, over and over again. Maven on the other hand arrives
with built in knowledge on how to build things, you are only required
to tell maven the basics, like the name of the artifact, the version,
etc. Maven does everything else for you without you having to tell it
how to do it.
As an ant+ivy user I have recently tried out maven
(yes, i hand-wrote poms for about 15 projects) which mostly depend on
each other, I got them all published in nexus etc. I must say that I'm
pretty shaken how unreliable maven build are.
I predict the core of your problem is "as an ant+ivy user...".
With ant, you adopt the mindset "I need to tell ant to do X, then Y,
then Z". With maven, you don't tell it how to do anything, it already
knows how to do stuff.
If you try and approach maven with the idea that you want to tell
maven to do X, Y and then Z, you'll very quickly come unstuck, because
you'll be fighting with maven, trying to convince it to do things in
your order instead of maven's built in order.
Maven already knows how to do stuff. All you need to do is fill in the
blanks. Tell maven what kind of artifact it is, what it is called. And
don't stray from the defaults - you don't need to put your source code
in some weird directory structure, if maven defaults to src/main/java,
put your code in src/main/java and leave it at that.
When you find yourself in a situation where you have a 50000 line pom
file, with hundreds of plugins all custom configured, you're fighting
against maven. This isn't maven's fault, this is the fault of the
person who created the pom. Keep it simple, keep it to default
behaviour.
With ant it either works or not. If it works, it works everywhere, in
console, in eclipse in hudson.
In my experience, I have not once encountered an ant build that
worked, ever. The reason was simple: the build is always secondary to
the code itself. Inevitably, the ant build only performed the basics,
even "ant clean" was left out most of the time. Every single one I
encountered had some or other path that was hard coded to "C:\Program
Files\..." with the developer expecting everyone else to just recreate
the same directory structure, it was ridiculous. Maven has gone off
and solved the build problem, it does not rely on every developer's
half hearted attempt to write a build script when they're under
pressure to produce code, not build.
At the core of ant is the question "how do I make ant do this?".
At the core of maven is the question "how does maven do this.".
Remove the "I" from the equation, and just do it like maven wants you
to do it, and suddenly everything becomes a *lot* more reliable.
I find it pretty hard to maintain versions with maven. Do I have to
make them all depend on RELEASE version of each other?
Yes.
The whole point of maven is repeatability. What that means
practically, is that ops call you and say "we have problem X in
production, v2.3.4 of the code, can you fix it".
If you cannot get v2.3.4 of the code - and by that I mean precisely
v2.3.4 of the code - up and running in your development environment,
you're toast.
To do that, v2.3.4 of the code must be built against a pristine tag.
And v2.3.4 of the code must depend on other jars who were also built
from a pristine tag.
What a SNAPSHOT is is a great big red flag that says "ALL BETS ARE
OFF". SNAPSHOTs are built from random untraceable working copies. You
should *never* allow a SNAPSHOT to find its way into production.
When you use the maven-release-plugin (and you should), it performs
all the checks and balances to verify that your build is entirely free
of SNAPSHOTs, and that your code is checked in cleanly.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
