geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: private repo in svn questions...
Date Thu, 04 Dec 2008 18:45:17 GMT
Kevan Miller wrote:
> On Dec 1, 2008, at 8:12 PM, 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?
> I'm not sure that load is going to be a big issue. There's one aspect to 
> hosting the repository in the same svn branch (e.g. 
> server/trunk/repository) -- these private builds are part of our release 
> voting process. To consider moving to a geronimo/repository structure, 
> I'd like to understand how we maintain appropriate control on these 
> artifacts (not saying it can't be done...).

This is the same concern that I raised in my response.  I don't know how 
we would control these artifacts in their current form if they are not 
part of a Geronimo server release process.

>> 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.
> Not sure that it's *necessary*, but it's a good idea. Although patches 
> give a better idea of the intent of these private builds -- they're 
> patches, not forks...

Right ... and I think putting just the delta in a patch rather the 
including the entire source helps to keep them patches and not forks.  I 
think managing the code changes could get complicated if we start to 
include all of the source - even if we include the patch as well - since 
it will be the source build that is validated with each release and not 
the application of the patch and build.  The patch would really be just 
a "bolt-on" that could easily get out of sync.

> At one point we discussed renaming these artifacts as geronimo artifacts 
> (e.g. 
> org/apache/geronimo/patched/jasper/6.0.18-G678601/jasper-6.0.18-G678601.jar 
> ). Would this be a better technique for solving the issue?

I'm concerned this pushes us toward forking the code as well.  Would 
that require that we maintain source poms with the appropriate package 
names and versions and a source svn from which to build the artifacts? 
At the moment we bypass all of this by simply renaming the jars as we 
check them into our repo.  Maybe that is already an issue, but it seems 
that releasing these as independent entities makes them more public and 
subject to more scrutiny (and possible mis-use by other projects).

View raw message