geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: M4 - QA Branch details
Date Tue, 12 Jul 2005 12:57:34 GMT

On Jul 11, 2005, at 11:07 PM, wrote:
> It seems that there is no practical way of removing all SNAPSHOTs  
> (without
> having our own specially built "temporary" versions).  For example,  
> I sent
> a mail to the cglib dev list asking them to post their latest  
> version to
> the maven repo and I haven't got a response in approx 2 weeks.   
> Maybe they
> are busy or maybe they are on holidays.  My point is that I don't  
> think it
> is always going to be possible to get a project (that isn't one of the
> projects we are tight with) to build a special version for us when  
> we want
> it.
> It appears we have already been building defacto releases of external
> libraries, e.g. the cglib library in our repo:

You're right - there is a problem we have to deal with, but I'd  
rather see us try another approach to make things very clear and  

For any code that we must do this to we could adopt a strategery :

1) Make a copy in Apache SVN.  This code must be appropriately  
licensed (the Apache License) and there should be a very clear NOTICE  
about the source, what we're doing, that it's not a fork, etc, etc....

2) Produce a jar :


3) put that in


So it's very clear that it's not a release by CGLib, but rather code  
from us, by us, from our repo.

> Maybe a compromise is to properly document in the release notes any
> special versions of code we have with the following information:
> * Have a disclaimer stating that a special version of the library  
> is being
> used temporarily and we plan on moving to the a formal release of the
> library as soon as possible.  Maybe mention there could be a  
> 'chance' of
> compatibility issues when we move to the formal version?
> * A description of why a special version of a library is needed and  
> what
> the library is used by
> * The version of the code that was patched
> * A link/reference to the bug/issue tracking records for the  
> problem with
> the library and the patch(s) that were submitted to the external  
> project.

Yes - all good, in that NOTICE in SVN, and also in the distribution  
release notes.


>>> Something I haven't considered is what if the SNAPSHOTs we are
>>> depending
>>> upon are also depending upon SNAPSHOTs.  Looks like we need to dump
>>> the
>>> whole tree of dependencies and identify where the SNAPSHOTs are?
>> Yes!  Get rid of all snapshots in anything we distribute as a release
>> of any sort.
> Are you suggesting in the M4 release?

I can dream...


Geir Magnusson Jr                                  +1-203-665-6437

View raw message