geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Independently version transaction and connector
Date Thu, 10 Aug 2006 21:19:15 GMT
ActiveMQ is a good example of how this can break down too... he are  
already using 2 different versions in the build... 3.2.4-SNAPSHOT and  

But hopefully, once we get our dependencies cleaned up in m2, and  
hopefully get the g deps to be based on the m2 deps, than this will  
be much easier to manage.

Anyways, I'd be happy to have less snaps... I can't stand how it  
slows down trivial build tasks... yes I know I can use -o, but I hate  
it even more when I do that and it gets 90% though and freaks about  
missing some dependency :-\


On Aug 10, 2006, at 2:08 PM, Dain Sundstrom wrote:

> On Aug 10, 2006, at 1:31 PM, Jason Dillon wrote:
>> On Aug 10, 2006, at 9:14 AM, Dain Sundstrom wrote:
>>> I wanted to get a general sense before discussing the details,  
>>> since there would be no point if were against independent  
>>> versioning.  I was thinking we should put each them in a tree  
>>> which is a peer to Geronimo trunk.  I also think we should  
>>> generally only use released versions of the jars in Geronimo  
>>> (i.e., no snapshots) for two reasons 1) it is much easier to  
>>> maintain from a build perspective and 2) is will push us to do  
>>> more frequent releases of them.
>> I don't think that #1 is really a valid reason... IMO that is.   
>> The more trees you have to build and the more version numbers you  
>> have to manage is inherently more complex and thus harder to  
>> maintain from a build perspective.  The only way it might scale is  
>> if we can:
>>  a) automate the entire process of multi-tree building and  
>> configuration version updates
>>  b) reduce the frequency of change in the decoupled components,  
>> thus reducing the need to build or reversion
>> (a) is a bit of work to put some more magic (and complexity) into  
>> Maven2... (b) seems to be negated by your #2 to push out more  
>> frequent releases... :-\
> I really disagree with you on this.  I think we should be treating  
> these modules (and more modules) like we do ActiveMQ.  AMQ moves at  
> it's own rate, and every so often we integrate it.  For another  
> example, is also how we treat commons logging.  The problems only  
> occur when you are highly coupled to version specific details of a  
> library, and this is why I think we should avoid SNAPSHOTS as it  
> pushes you to develop more decoupled code.
> -dain

View raw message