geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: private repo in svn questions...
Date Wed, 03 Dec 2008 03:05:12 GMT
I think this could become reality if we have a geronimo/repository in  
svn, then have it automatically exported to our zone for access by  
builds.  I still don't think that accessing the svn tree directly from  
maven is a good idea.


On Dec 2, 2008, at 9:08 PM, Joe Bohn wrote:

> Donald Woods wrote:
>> David Jencks wrote:
>>> In order to get the build to work with my use of nexus I've added  
>>> the trunk svn repo (server/trunk/repository) to the nexus  
>>> repositories.
>>> This makes me wonder if we should just set up a single repo in svn  
>>> and put all our private builds there rather than having branch- 
>>> specific repos.  Would this result in more or less or the same  
>>> load on the svn server?
>> Seems that moving the artifacts out into a unique svn branch (from  
>> geronimo/server/trunk/repository to geronimo/private/repo) would  
>> increase the load, as now every server build would be hitting the  
>> svn repo for artifacts (instead of just the /samples or /plugins  
>> builds.)
> I think there is value in having all of the required elements for a  
> G release in one svn branch.  It keeps everything together when we  
> release in the tag.  How would we manage the artifacts if there were  
> in a unique svn branch without the release process?  I know we don't  
> exactly release these artifacts as the specified versions - but we  
> implicitly release them when we create the Geronimo release.  Would  
> they ever move to a tag if they were in a unique svn?
>>> I also wonder if our policy of patching apache projects and coming  
>>> up with our own psuedo releases is really the best idea or if we  
>>> should just copy their code over in svn and build it more directly.
>> I could go either way on this.  I would like to see us at least  
>> check-in a tar/zip of the source for the patched artifacts into a  
>> branch, to make it easier to reproduce patched builds if needed  
>> (and so end users can rebuild everything if needed or used the  
>> patched source in a debugger.)
> I guess the benefit of including all the code in our svn would be  
> that a user could easily debug the code if necessary.  But I'm  
> nervous that the changes might be difficult to track and migrate to  
> newer releases without the patch (and an optional patch can be  
> easily ignored/forgotten).  So I think I favor the process as it is  
> today.  I think we really need to work harder to remove these  
> private builds.
>>> I also discovered a couple of weeks back that the lack of poms in  
>>> this repo was causing significant build delays while maven was  
>>> looking everywhere it could think of for them so I added them when  
>>> I could easily find them in the artifacts.  I think we should add  
>>> them for the other artifacts as well.
>> Agree.
>>> thanks
>>> david jencks

View raw message