I'm crossposting to both Alexandria-dev and Turbine-Maven-dev as I am
curious to know what these 2 projects think ... :-)
--
I've been playing a little with CI tools for the past week and it seems
to me there are 2 possible approach to such tools :
* Use a project descriptor based approach. This is what Gump and Maven
uses
* Use an Ant approach, i.e. the Ant build file contains the project
information, mixed with actions to perform on this data. This is the
approach that CruiseControl is following. It is a wrapper around a
master Ant build file.
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.
* 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).
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).
* When I tried Gump, it was real nice. With some minimal effort, I could
build my project (although I had duplicated definition of my
dependencies both in my project Ant build files and in Gump
descriptors). However, it was far from finished to make it a perfect CI
tool :
- working on all platforms
- deciding when to trigger a build (like every 10 minutes of CVS
inactivity, etc)
- sending emails
- deploying project deliverables and build logs to a website
- looping
- customization, like 10 unclean builds for 1 clean build (full
checkout), etc
Of course, I could have written batch files, perl scripts, even Ant
scripts to provide for this but then all the work is still to be done.
Ok generating a dependency graph is very useful when you need to build
50 projects but it is less crucial when you're working on a customer
project with only 4-5 dependent subprojects (for which dependencies can
easily be captured in Ant itself).
* 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
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'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 ... :-)
Thanks
-Vincent
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
