On 14 Oct 2010, at 7:00 PM, Leon Rosenberg wrote:
This isn't quite true since ant allows you to build 'your own maven'
in few hours. The effort to learn maven is much higher, at least I had
to spend a lot more time since now.
On the other side the effort to learn ant is moderate. But maybe I'm
biased here ;-)
Reading this, it's like saying "I hear you're building an airplane in
your garage, why all the trouble? You just take this piece of paper,
and fold it like this...".
And, you can't deploy with maven...
mvn deploy?
Which you would never do manually, because deployment is done
automatically during "mvn release:perform".
Well actually what bothers me is that my build scripts very shorter
than my poms. My typical build script in my pre-maven time was 3 rows
long:
<?xml version="1.0"?>
<project name="ano-prise" default="dist" basedir=".">
<import file="../build/basic-project.xml"/>
<property name="ivy.organisation" value="anotheria.net"/>
<property name="ivy.module" value="ano-prise"/>
<!--
checkout
svn://svn.anotheria.net/opensource/build/trunk as ../build
in order for this build script to work.
-->
</project>
Now take a look at this from the point of view of somebody who has
never seen your ant project before.
They check the project out, they see "build.xml", they than go "oh
cool, an ant build, let's try 'ant install'".
Error.
Oh, it's complaining about a file that doesn't exist in a directory I
don't have, no idea why, let me try and reverse engineer the ant
script. Oh look, I have to check out something else and stick it in
some directory structure. Oops, I already have a build directory, let
me rearrange the directories on my disk. Right, it's checked out, let
me try that again.
Error.
Oh, what is it this time. Reverse engineer the basic-project.xml. Oh,
they've called it "ant jar" for some reason, which was different to my
ant scripts from the other project, where it was 'ant install'. Let me
try "ant jar".
Error.
Oh for crying out loud. Reverse engineer the basic-project.xml.
Discover that someone made a change to the shared ant script to fix
the requirements of project Y, but that has broken project X. Let me
try and hack it to work. Ooh look, it works now.
Later, you check out project Y, and you try and build it.
Error.
Guy who wrote ant build script is spontaneously thrown out of the
third floor plate glass window.
In comparison, I might check out your project, look in the root of the
project and see "pom.xml". "Oh, cool, a maven build, let me go 'mvn
install'".
Done.
Well thats another point, what if I have more than one source code
directory? For example I have a project which contains an apt-based
code generator.
You don't know, and you don't care, because the maven plugin that
knows about apt-based code generation worried about that for you,
that's its job.
I have some projects that use the Torque database code generator. The
plugin has a default location it places the classes, and it tells
maven, and that path automatically appears in my Eclipse project when
I ran "mvn eclipse:eclipse". Again, I didn't know it was doing this
and I didn't care. I was too busy getting on with the job at hand with
code.
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 don't know.. I have use-cases over use-cases with stuff that maven
isn't doing per default.
Stop and think about that for a bit. Do you really have this use case,
or is it a nice to have?
Example: get cobertura/findbugs/pdm reports without site phase. I
actually expect the CI to call verify instead of building a site. I
spent three days trying to get a cobertura report out of verify and
finally gave up.
I type "maven cobertura plugin" into Google. On the opening page of
the first hit, under "goals overview", I see "cobertura:cobertura". I
run "mvn cobertura:cobertura". Done.
Example: pack and unpack additional files into jar files. We have a
project which is an embedded-tool for webapps, similar to
tomcat-manager, but inside the webapp. We are used to package it as
jar and include jsp/img/js/css files into it, and unpack them in the
process of building of the final war. Manageable with maven? Yes, but
a lot of code.
Why are you trying to insert additional files into jar files? When you
build the jar file, use the maven-resources-plugin to insert the
additional files in the right place from the default src/main/
resources directory. Once released, the jar is sealed, you don't touch
it again.
Fiddling with jars after release is evil beyond words. I was involved
in an outage where we had to get the code running in production up on
a developer machine to reproduce a bug. Oops, the code didn't build.
How on earth did code that didn't build end up in production? Sheepish
admission from project developer: "I might have added an additional
file to the jar after the release was finished, as I didn't want to
bump the version number".
Don't do it.
And than this uncertainty. We need to add some files to the war...
Lets add them as ressource, no didn't work, ok lets use build-helper,
no wrong, aaah this time its the war plugin which needs to be
customized... a lot of trial and error is needed to achieve what you
want.
Don't do it.
Unfortunately this makes the whole maven managed dependency absolutely
useless. If I rely on SNAPSHOTS I can setup a nightly build in hudson
that checks if the latest changes in one of the projects break
dependent projects. I can even do it on each commit. That's a really
great CI. However if I go for RELEASE the dependencies aren't there
anymore and I don't want to release a new version each night or on
each change just to see if it broke. RELEASE is pretty good for
managing static dependencies but sucks for CI. SNAPSHOT is great for
CI but suck for releases. Is there a world in which both use-cases
work?
Having repeatable production builds is orders of magnitude more
important than having gump style bleeding edge CI. To prove this,
follow this simple test: Don't provide gump style bleeding edge CI,
and see how many calls you get. Now, insert an error into production,
and see how many calls you get.
Gump style would be a very nice feature to have, but it by far and
away is less important than repeatability.
I'm not flaming maven, it's a great tool for some kind of problems,
but its definitely not a holy grail. And right now I'm talking to my
guys to switch from ant to maven, and I'm missing arguments.
There are two perspectives to approach this from, from the perspective
of the developer that wrote the initial code, wrote the initial ant
script, and structured everything exactly as they wanted it, and from
the perspective of the developer who comes after, has to learn how the
custom ant script works through a lengthy reverse engineering and
trial and error process.
From the first perspective, it is entirely understandable that
someone would use ant. It works for that developer fine, so no problem.
But from the second perspective, that custom ant script becomes a huge
liability to the future maintenance of the project, and it is at this
point where maven really shines.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
