Hello,
On Wed, Oct 13, 2010 at 10:53 PM, Graham Leggett <[email protected]> wrote:
> 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.
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 ;-)
And, you can't deploy with maven...
>
>> 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.
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>
>
> 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.
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. The other source-directory of the project is annotated
with apt annotations from the first source part and can't be compiled
before the first part is compiled. Further on, the generated code
itself has to be compiled as well. And yes it works with maven and
some plugins but in much less elegant way as in ant.
>
> 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 don't know.. I have use-cases over use-cases with stuff that maven
isn't doing per default.
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.
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.
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.
>
>> 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.
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?
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.
regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
