On Thu, 2003-01-02 at 09:10, 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.
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. > 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. 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. It is very fast and getting faster. It's basically XSLT with object access. DVSL has been fully replaced in CVS HEAD. But I would never stop anyone from using what they want and if it makes it easier for you the forrest plugin can be distributed right now. I personally don't like cocoon much but I'm not going to block attempts by anyone else to use it. If Jeff wants to put the Maven plugin in CVS I don't think anyone would object to giving him access to maintain it until we get the plugins out of the core. As for plugins in general, they will use the same mechanism other dependencies use. So if a project states the need for a particular plugin it will just come down like any other dependency. The general mechanism is in place and the touchstone build in maven has a sample using a WAR file as a dependency. > * 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? As to the former I'm really no judge as making plugins: for me it isn't a challenge but I'm sure others may find it quirky. 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. There are also dynamic tag libraries using Jelly, you can put these in any file you like and import them using Jelly. This is the same strategy we use for making plugins. Many plugins simply consist of dynamic tag libraries that can either be used by other plugins or the end user. > * 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. 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. > * 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. > * 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. > -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. > 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? No, there is a mode for offline use that doesn't require you to be connected at all. > > > -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. > 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. 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. 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. > 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]> -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
