jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <cml...@gmx.de>
Subject Re: Building Cactus with Maven -> I'd like to volonteer
Date Wed, 25 Jun 2003 12:35:31 GMT
Vincent Massol wrote:
>>Let me add a couple of concerns/requirements:
>>
>>- We should not depend on Maven CVS HEAD or SNAPSHOT-something for the
>>build, only on a released "stable" version. Of course that would slow
> down
>>the migration if our build requires changes to Maven, because we'd
> need to
>>wait 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

>>- 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 it
> may
>>conflict 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,
> it
>>seems like many Mavenized projects either don't care about Gump, or
> keep a
>>separately 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 should
> be
>>possible 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



Mime
View raw message