"Vincent Massol" <[EMAIL PROTECTED]> wrote on 03/04/2002 07:32:32 AM:
[snip]
> I'm still not sure which one is the best but if I had to make a choice
> today, I would be tempted to choose the Ant-based approach for the
> following reasons :
>
> * Continuous Integration is about building projects and it happens that
> Ant is more than a build tool, it is a build platform and thus, from an
> architecture point of view, it makes sense to me to use Ant as the
> infrastructure to build such a tool. Same as it would make sense to me
> to use Eclipse or Netbeans if I had to write a Development Tool.
Hence Maven inherently uses ant as part of its infrastructure.
> * I fear that the problem with making a generic Continuous Integration
> tool is that requirements from different projects are well ...
> different. And thus to accommodate everyone, we'll find that our initial
> Project Descriptors which fine neat and small will tend to grow big ...
> and reinventing a description language a la Ant in the end ... For
> example : take the latest discussion on the maven mailing lists. Someone
> said "I need a war construct". Ok, then you add <war/> element in the
> descriptor. Then someone else says "But in my project I need to generate
> more than 1 war". Ok then you add <war><fileset/></war>. Same thing for
> <checkstyle> ("but I don't want to run checkstyle on my full src/
> directory as I have some AspectJ code there", etc. Then you add an
> <aspectj> tag, etc). There isn't a one size fit all in term of project
> descriptors. An Ant approach is more flexible (although it is probably
> more work for a user).
This is the point of a mailing list - discuss the good and bad ideas
everyone has, and come up with the best fit.
I think the point of the descriptor approach is not to model the *tasks*
being performed (that happens in the build file used to generate
deliverables), but to model the project structure itself, so that any set
of tools can be easily applied to the project.
'The Ant approach' is part of what Maven does, but it does it in a
standardised and consistent way. There is a large amount of effort that
goes into building what I'd consider simple build files and keeping them
up to date. 'Best practices' are hard to follow as well, as they change
over time, and build files become legacy code.
> That said, it could work on a restricted scope (not sure Jakarta is a
> restricted one though :-)). It would be possible to say, in our
> community, all our project must have a project descriptor and not use
> Ant build file, which would give all the projects a common directory
> structure and such (but also prevent new ideas and cross-fertilization
> unfortunately).
I don't think that's what it's about, though. Noone wants to stop people
using Ant in whatever way they see fit. But what we do want to do is make
project information accessible, easy to use, easy to generate and easy to
update.
[snip gump stuff]
> * One thing that look sure is that when you start working with a Project
> Descriptor approach, you have a model in memory and it's very difficult
> to use a build script like Ant to provide some features (how do you
> transfer the model?). Thus is forces you to go all the way. The ideal
Not really...Maven accomplishes this, as does Krysalis, by using an Ant
task to 'expose' the project model as properties. See the project-properties task.
> solution would be to express only data in a Project Descriptor and have
> an Ant build file for executing all "actions". But how do you bridge the
> gap ?
I think this is the approach Maven is taking: be a project object model,
and use ant as the build tool. Krysalis (from memory - someone else feel
free to set me straight) is doing the same thing, but using a gump project
descriptor.
> I'm curious to know what your opinion is. I don't think there is one
> answer. You have to balance flexilibity vs ease of use. Maybe a
> templating engine in Ant is the solution ... :-)
I think we have enough templating engines :) What we need is to make using
Ant, and getting a project to a 'decent' state, as easy as possible.
Commons is a classic example of why an Ant-only approach doesn't cut it
IMHO. Project developers (us) find the update of docs, stats, test
compliance and other info tedious, and hence don't do it.
As a 'test' I recently had a look @ dbcp on commons to see what it would
take to 'maven-enable' a simple project. Capturing the info about the
project took about 15 minutes, including finding out what jars were
'really needed', and not just what was listed in their properties file.
Once I'd done that I could produce all the current project deliverables,
plus a project site complete with test case results, metrics, developer
lists, mailing lists, changelog etc. It would take me that long to cobble
together a build file to do it, and I'm sure that build file would be
missing one of those features.
For me the proof is in the pudding. That's my $AUD0.02c - currently about
a US penny :)
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
