avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject RE: Build Environment
Date Thu, 02 Jan 2003 17:20:40 GMT
> From: Jason van Zyl [mailto:jason@zenplex.com]
> On Thu, 2003-01-02 at 09:10, Berin Loritsch wrote:
> You can also look at the plexus build, which is an Avalon 
> container with
> many components. Doesn't take much to build them all in the correct
> order.

Can you post a link?

> I myself don't have much interest in Forrest and I'm not out to pander
> to Avalon so I haven't done anything on this front as I'm focusing on
> JSL for the documentation transformation mechanism.



> > * Not easy to extend with user defined modules, it requires user
> >   intervention to install project specific modules.
> You mean the plugins are not easy to create or that users need to pop
> them in?

More the latter.  I haven't tried to actually create the plug in.

> As for the
> latter, a plugin can be made a dependency and be dragged down with CVS
> HEAD but I think I am going to add some specific handling for 
> plugins to
> make things transparent. The whole mechanism is there but it requires
> some end-user sugar coating.

It looks like the major plugin complaints have been answered then.

> >                          -o0 Weaknesses 0o-
> > 
> > Maven
> > -----
> > * No way to "seed" a new project like Forrest does.  I think work
> >   might be underway for it though.
> There is now a base plugin for populating projects which can 
> be extended
> to provide a general generation mechanism. I'm using it to create a
> Plexus plugin and a Summit plugin. We will also use it for other types
> of apps as well. Dion I'm sure will make one for a struts application
> and I will do one for a simple velocity webapp.

Exellent!  That looks really good.

> > * 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.
> That's been fixed in CVS HEAD. Everything is lazily loaded now as
> requests for functionality hit the wire. When you install 
> Maven it won't
> try to satisfy the dependencies of all plugins. It will 
> satisfy them as
> you need them. So no more downloading 5mb of AspectJ jars.

Great! let me know when you make another release!

> > * 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.
> The plugin mechanism is certainly evolving quickly but its stabilizing
> as I add more unit tests and adding more integration testing 
> in the form
> of a touchstone build. Again, the forrest module won't be an 
> issue. You
> can put it in maven cvs today if you like or you can wait for 
> the 'maven
> plugin as a dependency' feature to surface.

Yes.  We are also considering a plugin for dependency graphs.  I.e.
XYZ subproject requires ABC lib, which requires DEF, GHI, and Foo.
It will help with writing the docs that describe what a distributed
piece of code requires.

> >                        -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.
> Maven at one point had _great_ documentation due to Pete Kazmier but
> that all was laid to waste once we switched to Jelly. I'm 
> trying to coax
> him back into making some more docs but I don't think he'll attempt
> anything on the order of his massive initial effort until 1.0 is close
> to fruition. Changes happen and it's unfortunate that we lost all that
> great documentation we had but Maven did initially have 
> awesome docs and
> it will return, eventually.

I remember!  That is one of the things that really turned me on to
Maven.  I look forward to the day when things get better.  It was
a general observation.

> > Maven
> > -----
> > * What happens if I don't have an internet connection after I do
> >   the initial install?  Will it be useless?
> No, there is a mode for offline use that doesn't require you to be
> connected at all.

Even if it has never been run yet?

> >                      -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.
> We go as we go. I have been thinking about Maven for a _long_ time and
> will push it to completion. I'm familiar, as I'm sure you know, with
> quirky, error laden builds systems that span multiple projects and
> repositories. I would like Maven to take care of as much as 
> possible and
> I believe it is almost there.


> If you go tracing back through the archives you find that I was the
> impetus for any of the tools in use. JJAR was spawned directly from
> something I asked for from Geir. We subsequently had 
> disagreements and I
> still firmly believe JJAR is a dead-end as it is yet another 
> descriptor
> (a monolithic one) and it's a bad mixture of concerns dealing with
> transport and dependencies. The graph code in the graph2 module is
> better. Both versions of the graph packages in the commons came about
> due to me soliciting code from Markus Dahm and David Peugh. A reliable
> graph package is essential. The resultant contract-based package that
> exists, thanks mostly in part to David Peugh, works wonders in the
> reactor. There are 50+ plugins in Maven and the reactor 
> builds them all
> in the correct order without difficulty. I mean directed graphs aren't
> rocket science but the graph package I felt was the way to go.

Is the graph package available to everyone?

> Look back in lots of places and you'll see lots of code that has been
> made and/or tailored for Maven purpose of creating a coherent object
> based build system. Digester rules, betwixt changes, Jelly, Werkz,
> Classworlds. A thriving ecology of really good projects: all 
> which will
> lend toward having a good project comprehension and management tool. 


You know, now that you made this post, it makes my decisions even harder!
;P  But that is a *good* problem to have.  I am also glad that the Avalon
team has heard representation from both of the prospective build systems
so that we can make some fair comparisons.

With the stuff coming down the pike, I would like to revisit this after
the next release of each project (provided it isn't months away).

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message