We have already identified our build environment to be somewhat
lacking. The number of JARs that we need to hold on to, and the
number of files we need to keep track of, is extensive. As a result,
before a release we have to debug our build environment along with
our code. It is a time consuming job we shouldn't have to worry about.
To fix the problem, I proposed Maven, and Nicola counter-proposed
Centipede. Since I don't want to speak about things I didn't know,
I decided to create a new "avalon" directory structure on my machine
to experiment with the two build tools. Both have changed a fair
amount since the last time I performed this excersize. Neither are
a perfect match (again), but they are both far more user friendly.
I figure that if I post this here, and copy the respective mailing
lists, it will generate discussion and action in the respective groups
again. Below is a list of strengths and weaknesses of each project.
This is from the viewpoint of a user who doesn't know (and quite
frankly doesn't care) how the internals work. I used the latest
release from both projects--not the current CVS.
-o0 Strengths 0o-
Centipede
---------
* Integrates with Forrest, which I also like by default.
* Easy to extend for our purposes. User defined Cents are easy to
develop and incorporate.
* Declarative project descriptor integrates with Gump easily--it
is merely an extended Gump descriptor.
* Provides an interactive build if the user does not specify a
specific target. It is a great help to those who are just learning
how to make builds.
Maven
-----
* Integrates with Forrest, but not by default.
* Not easy to extend with user defined modules, it requires user
intervention to install project specific modules.
* Project descriptor is declarative. It is intuitive and
easy to understand. All a user needs to know is how to declare
dependencies, and Maven takes care of it.
* No explicit build script is needed. Maven fills in the blanks
itself.
* Not cluttered with messages that do not mean anything to the user.
The build output provides enough information to know that things
are working, and not so much that problems get hidden.
-o0 Weaknesses 0o-
Centipede
---------
* The project descriptors are not as easily intuitive. You have
an XML based properties file, as well as a meta-build ANT file.
Why not just declare everything once like Maven, and take care
of the dependencies automatically.
* Centipede's default install does not automatically download and
install missing cents. Cents are required for Centipede to do its
work, but all the required Cents are not included for some strange
reason.
* In the absence of a meta-build ANT file, Centipede does not provide
a way to "seed" a new project like Forrest. It should be easy to
do, and it would be better than trying to figure out what to do
from the site documentation.
* Way too much information spit out at the user. Mountains of log
files go by, some of the actions appear to be recursive (which
always makes me nervous), and there is no intuitive way to lower
the threshold of the log messages. I am not trying to debug
Centipede--I just want to debug Avalon.
Maven
-----
* No way to "seed" a new project like Forrest does. I think work
might be underway for it though.
* Maven downloads alot of stuff to get started. If you don't have
a fat internet connection, your first build takes a really long
time.
* Difficult to extend with project-specific modules. The machinery
is there, but it has a lot of rough edges. The Forrest module is
not included by default.
-o0 Unclear Things 0o-
Both projects have the typical Open Source failings. Documentation
is sparse, and typically only covers what the developers were
concentrating on. For example, both focus more attention to
_converting_ an existing project than to _creating_ a new project
from scratch. Between the two, Maven does have marginally better
documentation.
Centipede
---------
* It looks like Centipede might be able to function like Maven to
download dependencies on demand. I just can't seem to figure out
how it would work.
* Can I declare my build properties in a Properties file? It would
actually be more intuitive than the XML variation, and a lot more
dense. XML is not a panacea--it is a tool, and for this purpose
it is overkill. It works quite well for the project descriptor,
but not for properties.
* If I use Forrest directly, I can stick my doc files in
src/documentation/content/. If I use it through Centipede then
I have to stick it in src/documentation/content/xdocs/. There
is a mismatch.
Maven
-----
* What happens if I don't have an internet connection after I do
the initial install? Will it be useless?
-o0 The Bottom Line 0o-
Neither build system is perfect. After my excersize, I have come
to the conclusion that Maven is the more mature of the two build
systems--but Centipede is catching up fast. In fact, if the current
pace of development for the two projects continue, Centipede may
very well overtake Maven in features and ease of use.
I think Maven has a lower barrier of entry to the user, but
Centipede is becoming easier to use and more developer friendly.
I am a fan of black box tools like Maven, but if I need to do
something a little out of the ordinary, I like the flexibility
of Centipede.
For Avalon, I want to depart from the hienous build system we
have now. We have stretched ANT to its limits, and have many
many JARs in our CVS. Our recursive build in Excalibur is
problematic, and there is no clean way to simply declare
dependencies--or even create a dependency graph. When you have
one project that depends on another, that depends on yet another,
you would like to know all the dependencies that are required
for your build. Also, we (or is it just me?) would like to
provide two versions of a project--A smaller JAR where the user
has to include all the other dependencies, and a larger JAR
where all Avalon code is included--making it easier for a
user to use some of the larger and more complex subprojects.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
