geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Independently version transaction and connector
Date Thu, 10 Aug 2006 23:49:02 GMT

On Aug 10, 2006, at 2:54 PM, Kevan Miller wrote:

>
> On Aug 10, 2006, at 5: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.
>
> I'm about two hours late for a vacation, but some quick comments...
>
> I'm kind of hesitant about this. Makes me think of our Spec jars...  
> If there are frequent Geronimo releases, how important is this?  
> (sorry, i haven't read the previous notes). If Geronimo isn't  
> releasing fast enough, I can imagine the hodgepodge of different  
> versions -- that ends up confusing us and users... Also, we're  
> already coordinating "joint" releases of TranQL, OpenEJB, etc.  
> Isn't this adding more?

I guess the simple perspective I have on this is that Geronimo  
doesn't need TranQL or OpenEJB to compile.  It's the other way  
around.  The Transaction and Connector code is perhaps OpenEJB's  
biggest dependency on "Geronimo" aside from the deployment code.

If we hope to see a day where OpenEJB isn't dependent on Geronimo  
snapshots to compile (and Geronimo on OpenEJB snapshots to assemble),  
then we definitely better take this forward step.

I can see this being a concrete step to allow us to potentially do  
"phased" releases, cause certainly doing big "joint" releases sucks :)

-David


Mime
View raw message