Re: Build Environment

I have integrate Maven with my phoenix project since 2 months now and 
i'll share my experience as a user. I am still using ant for every task 
requiring xdoclet. This include generating altRMI code and meta 
information. I could have integrate it into the maven.xml file, but I 
didn't want to spend to much time on it. The best solution would be the 
creation of avalon-specific reactors (I think the term reactor is 
appropriate to define a maven module). To me, Maven is exceptionally 
useful when compiling and unit testing my code, on which  I spend most 
of my time. It is really straightforward to build/install/integrate 
Maven with your existing project and compilation is much faster than 
ant when calling "maven console" followed by "test" at the prompt line. 
To answer one of your concern about Maven, you do not have to be 
connected to the internet as long as you dependancies declared in your 
project.xml file satisfy your maven's repository. There are some naming 
convention to be used to, and then you can manually add your jar into 
the filesystem directly.

David


On Thursday, January 2, 2003, at 06:10  AM, Berin Loritsch wrote:

> 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]>
>