Let me add a couple of concerns/requirements:down
- We should not depend on Maven CVS HEAD or SNAPSHOT-something for the build, only on a released "stable" version. Of course that would slowthe migration if our build requires changes to Maven, because we'dneed towait until those changes get incorporated into a release.
Hum... Why not view it this way: - we use the latest Maven from CVS (we have to) to create the build system - once we consider it good enough for our users we wait for a stable Maven release and announce it as ready.
Okay
may- Instead of putting the Maven-based build into a branch, we should be able to just put it in CVS HEAD. But maybe I'm missing something, and itconflict with the Ant-based build?
No it's not conflicting. I'd just not like to commit something that is half working in HEAD for the 1.5 release with is Real Soon Now (TM) :-)
Oh yes. We *really* need to get this release thing sorted out... sigh
- The Ant build files remain the authorative, official build process *until* a vote is casted and agreed upon to completely switch to Maven.
Yep. Agreed.
- Cactus *must* be buildable by Gump. While I don't know the details,itseems like many Mavenized projects either don't care about Gump, orkeep aseparately maintained Ant build file. IIRC Maven can autogenerate Ant build files, but how well does that work for a non-trivial project?
Not sure here. I'd say the requirements is that there is at least a nightly build done with recent versions of dependencies. I'm not sure it has to be done by gump though. But ok to start with this req.
I'm sure the Maven community is planning the next big thing to replace Gump ;-)
Anyway, I'd consider moving away from Gump a very radical step. OTOH I think we have been stretching Gump a bit, by trying to make it generate our nightly builds, publish our website, etc.
I have been thinking about setting up CruiseControl somewhere to do nightly builds. In contrast to Gump, it'd use the lated released version of any dependancy, because that's also the baseline for releases. It would upload the files to our nightly build area, and publish the website, including Clover coverage reports etc. So we'd have more reliable nightly builds and website updates, while the integration builds would be performed by Gump.
When moving towards a release, we could even promote an existing stable nightly build to beta, rc or release status (similar to what the eclipse guys do AFAIK).
The only question is where that should be setup. I will probably start on my home machine, and see how well it goes.
- I don't like the default Maven documentation/site style. It shouldbepossible to keep our current style, which we put a lot of work into.
... or improve the Maven style... ;-)
Nah, I really dislike that so many of the Maven generated sites look exactly the same. Cactus is a Jakarta subproject, and should strive to keep a somewhat consistent look with the rest of the family (too many subprojects ignore this already, many of which have left the jakarta umbrella recently).
It's not that Maven doesn't allow pluggable styles, is it?
Honestly, my interest in moving the build to Maven is twice: - get a simpler build system for Cactus - at the same time, test and improve Maven using Cactus as a guinea pig. In other words, I trust in Maven but it has some rough edges and using a real and complex project to smoothen them is the best way to go I believe.
If it makes the build simpler, cool.
If it's just about auto-downloading JAR files, we could also add an Ant script similar to what the Tomcat folks have done. A benefit of that approach is that the downloading is optional and only performed when the user explicitly requests it.
-chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
