Leo Simons wrote:
I like gump [1]. Do you?
A RT: how does it compare in terms of features with other continuous-integration packages out there, cruisecontrol, damagecontrol, etc ... ?
It's "different" in many ways. One of the main selling points (and the main reason for its complexity, too) with gump is that it completely "overrides" the classpath management in ant (maven is a "todo") and builds a classpath of its own that is comprised of the source that it has just built.
There's also a lot of things that it does less well than other continuous integration packages; for example, gump runs roughly every three hours, not on every cvs/svn commit.
The main thing about gump is that its the dominant tool used at apache, ie it is what nearly all our dependencies use and what near all our dependees use. It's an ASF project in active development. This is perhaps a more important point than you realise at first. Many people (often gump fanatics!) feel participating in gump is part of "playing nice" with many other java projects here at the ASF. For example, I think cocoon would be quicker to get rid of any excalibur dependency if excalibur were to no longer participate in gump runs.
I consider myself biased in regard to gump. I'm a committer and PMC member over there. Best to disregard my opinion :-D
I personally think excalibur should participate actively and "properly" in gump builds. What I don't like is maintaining that gump integration all by myself (or with a small subset of the active committers) and having to fix things that get broken because some people are not aware how gump works. That's how it has always been @ avalon, and I'm not prepared to keep that rhytm up. No fun.
Are you guys prepared to invest the neccessary time and energy to maintain good gump integration? How much energy?
how much effort and energy is required to keep up gump integration?
There's basically two things to gump integration:
1) having an automated build that gump knows how to call (ant or unix scripts, with maven support in beta)
2) telling gump what to build, how to build it, and what the end results are supposed to be by maintaining a gump descriptor in gump cvs
The answer to your question depends on many things. Right now, most maven-built projects maintain gump descriptors (like the gump-build.xml files in our repository), often autogenerated using the maven gump plugin, but somewhat cumbersome nonetheless.
That is supposed to be changing (gump reading the project.xml and calling maven directly), but OTOH that work has been underway for months and ain't finished yet.
If you use ant, that's currently a little easier.
What also matters is how often stuff moves around, how stable our dependencies are (if they break a lot its annoying), how many seperate buildfiles and targets you have (if you have one build.xml you have one gump descriptor, which makes life easier).
Gump also has a learning curve. It has a descriptor somewhat like the maven project.xml (but predating it and rather incompatible) which requires some experience to get right, especially when writing a new descriptor from scratch for the first time.
Again, most of these things I'm not the best to comment, since I've had that learning curve ages ago (back when gump was based on XSLT instead of java!), know where to change what when things move around, etc. For me personally, in private projects, the effort is nearly negligible since if I refactor the build I'll change the gump descriptor at the same time.
Niclas, care to comment? (Niclas and Steve spent a lot of time furnishing avalon into proper gump shape over the last few months)
cheers,
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
