commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [site] Gump Builds
Date Sat, 10 Apr 2004 15:59:33 GMT
Mark R. Diggory wrote:
> Lets push this to another thread because its such a great topic in and 
> of itself.
> So I think we have several needs here:
> 1.) nightly builds of jars that can be available to developers
> 2.) Integration testing across all the commons
> 3.) Automated Site updating/generation.

All great ideas.  We have 1) now via the commons nightly build process and 
2) is largely in place via the jakarta-commons gump module (though it uses 
ant and does not include all projects).  Item 3) would be a *big* 
advantage and would eliminate the need for ssh access to update the site. 
  It might also solve another open problem that we have in terms of site 

A while back there was discussion of a "staging / build" server where we 
could build a pre-image of the production web site (so the current site 
would be always be recoverable without having to rebuild everything).  If 
the "clean environment" that Adam refers to below could be that server (or 
could push to that server on success) and we could use rsynch (as I think 
Noel had suggested) to automate the push to production, this might be an 
effective way to keep the commons web site both up to date and recoverable.

Can gump help us do this? Is there any way, using gump and maven 
cleverness, that we can separate the site generation from the integration 
build?  If we could do that, we could leave jakarta-commons alone (just 
add ant-based descriptors for the missing projects) and create 
jakarta-commons-site just to do the site build.


> Adam R. B. Jack wrote:
>> Mark,
>> Have you thought about enlisting the help of Gump for the manual effort
>> here?  We are trying to allow Gump to be able to use Maven (instead of 
>> Ant)
>> for projects that prefer builds this way. We are making progress (with 
>> the
>> mechanics) but [don't know if you've read the list/archive] the main
>> sticking point seems to be group/artefact ids (something you know plenty
>> about.)
> Can you outline what you finally resolved to concerning what the 
> artifact/group ids should be for gump builds which use maven?
>> If you are interested, Gump ought be able to make this task a bit 
>> easier on
>> you, and automatically (nightly or more) do fresh runs (in clean
>> environments) for you.
>> Just a thought.
>> regards
>> Adam
> I'm just mostly unsure where to begin with getting with the Gump. I 
> suspect we would register each project with gump and let them get built 
> separately?
> -Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message