geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
Date Mon, 11 Aug 2008 15:16:40 GMT
I've updated the following to include a new repository module that 
refers to the correct svn location for our private artifacts -
	samples/branches/2.1 - uses server/tags/2.1.2/repository
	samples/trunk - uses server/trunk/repository


Donald Woods wrote:
> For 2.1.x based subprojects, I'm thinking of going the route of creating 
> a repository/pom.xml in each subproject that points to the 
> server/tags/2.1.2 directory for the private artifacts (since it may be 
> awhile until we release a 2.1.3 server and we want to get the 2.1.2 
> Samples and GEP out ASAP.)
> For 2.2 based subprojects, I like the idea of publishing the patched 
> artifacts under a org.apache.geronimo.patches groupid and will work on 
> that solution as soon as I finish updating the 2.1 subproject builds.
> -Donald
> Kevan Miller wrote:
>> On Aug 7, 2008, at 8:26 PM, Donald Woods wrote:
>>> True, but wouldn't that introduce the overhead of our release process 
>>> and voting?
>> I wouldn't call it overhead. I'd call it oversight. Our community is 
>> releasing the patches and publishing the binaries. Server release 
>> votes have covered this, to date. Any process changes must maintain 
>> this same level of oversight.
>>> Would we create a geronimo/patches subproject arranged like our 
>>> specs, where each artifact would be its own subdir and still check 
>>> the patched artifacts in for the build to use and then move them to 
>>> tags after they are released?
>> We could release them separately. Or, we could include them (as they 
>> are currently) in the server. The difference is that there would be 
>> org.apache.geronimo.patches artifacts in our release and snapshot 
>> repositories.
>>> Would we version the artifacts based on the originating project or 
>>> with a double version like we specs (which would be hard to follow)?
>> Either way would work. For simplicity, my tendency is to include them 
>> in our server tree. However, there may be differing opinions. I'm fine 
>> either way...
>> --kevan

View raw message