Which outlines all that I think is wrong with GUMP.
1) You can't try it yourself locally before committing.
you can but it is a pain in the $*!# to setup as you need gigs and gigs of diskspace and running it takes a long time.
2) You have dependency information in several places.
yep.
3) Building with gump is vastly different from just building.
the thing gump adds to the "just building" is classpath management (ie override). Any system that works with existing ant build systems has, I think, no other option. Either one must extensively modify ant or move to something else.
4) Building with GUMP is not a single command, it is a ritual.
when you have all of gump installed (like on nagoya) on a server, you can run gump with './cvs/jakarta-gump/gen.bat; ./update all; ./build all'. Add that line to a crontab and its automated. On the client side you can verify syntactic correctness of your configuration (using the 'ant gen' target), but you cannot tell the server to immediately check your changes.
When picking a build system, I consider these things (among others) important:
+ You should use the same system for *every* build. All the time. You use X for building on your machine, you use it for nightly/daily builds, etc. That way, you know that if it builds on your machine, odds are better than 99.999% that it will pass the nightly build.
+1
+ Dependency information is kept in ***one*** place.
+1
+ Easy to use.
+1
Gump fails all three.
Given the design requirement of not or barely impacting the existing (well, used to be before centipede & maven) de facto standard of ant-based buildfiles, it is very difficult to satisfy those other goals you list, without redefining or heavily modding ant. This is mostly because ant doesn't provide a mechanism for defining inter-project dependencies.
You should understand the context in which GUMP was created (http://jakarta.apache.org/gump/why.html). It has broken quite a few lances for continuous integration, and it does its job. Until there is a better alternative one should be moderate with criticism, or act on it :D
How is Maven in comparison?
Jason has sketched out plans for (forgot the name) a piece of software which will provide continuous integration based on maven POMs instead of on ant buildfiles (see this lists' archives and maven-dev archives). I'm not sure how far along this effort is, but I believe the timetable for arrival is a few months (unless people help write it of course, Jason's asked for help on it). My guess this is going to turn out as a continuously running service, similar to some of the existing commercial tools, but compatible with maven.
Until that project arrives on the scene, maven can't really be used for continuous integration testing, so no comparison is possible.
cheers,
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
