[site] Gump Builds

["Mark R. Diggory" <md...@latte.harvard.edu>]

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.


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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [site] Gump Builds

["Adam R. B. Jack" <aj...@trysybase.com>]

Sorry folks, I almost missed this (given it was weekend and the traffic on
this list). If you want to discuss this further, mind joining folk on the
general@gump.apache.org list?  [I don't know if cross posting is considered
poor form or not in a case like this, and is a solution.]

If not, I'll try to watch for subjects with 'Gump' in them on this list.

regards,

Adam
----- Original Message ----- 
From: "Phil Steitz" <ph...@steitz.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Saturday, April 10, 2004 9:59 AM
Subject: Re: [site] Gump Builds


> 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
> recoverability.
>
> 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.
>
> Phil
>
> >
> > 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: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [site] Gump Builds

[Phil Steitz <ph...@steitz.com>]

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 
recoverability.

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.

Phil

> 
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org