geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [DISCUSS] Release Geronimo components 2.2 (tx manager / connector)
Date Sun, 06 Sep 2009 07:00:31 GMT

On Sep 3, 2009, at 11:48 AM, Guillaume Nodet wrote:

> I've slightly enhanced what you did.
> Mostly, I've added the following lines:
>
>                         <Import-Package>! 
> org.apache.geronimo.connector*,*</Import-Package>
>                         <_versionpolicy>[$(version;==;$(@)),$ 
> (version;+;$(@)))</_versionpolicy>
>
> The first line is to ensure that the bundle won't import the package  
> it exports.  Such a thing is ok for an api, but not for an  
> implementation / library as you certainly don't want to use classes  
> from another version of the bundle.

I'm confused by this.  I've never seen anyone else claim that not  
importing everything that is exported is a good idea and definitely  
thought the best and highly recommended practice was to always import  
everything you export.  Do other people agree with you on this?  What  
problems would arise if we imported everything that was exported?

> The second line makes sure the version uses ranges by default such  
> as [2.1,3.0), meaning any version >= 2.1 and < 3.0.  This assume  
> backward compatibility between minor releases.  FWIW, if you don't  
> put anything, it would be [2.1,), meaning anything >= 2.1.
>
> For the javax.resource package, it can't really be optional, as the  
> GeronimoTransactionManager implements javax.resource.spi.XATerminator.

Agreed.
> If we want to not import this package, we could add this only class  
> to the bundle and not export the package.  That would mean the maven  
> dependency could be removed altogether ...

That doesn't seem like a good idea to me.  Wouldn't it result in a  
split package?  If we wanted to avoid requiring the import then  
perhaps we should have another txmanager class that doesn't claim to  
implement XATerminator.  At this point I'm happy keeping the import.

thanks
david jencks

>
> On Thu, Sep 3, 2009 at 19:04, David Jencks <david_jencks@yahoo.com>  
> wrote:
> I thought I had already bundleized 2.1.... since we are using the  
> 2.0.0 bundle plugin a direct merge or [1] won't work.  In the  
> interests of my learning how to set this stuff up I just committed a  
> bundleization of 2.1.  Can you please check it?  In particular,  
> should the import of javax.resource in txmanager be optional?
>
> thanks
> david jencks
>
> On Sep 3, 2009, at 9:18 AM, Guillaume Nodet wrote:
>
>> I'd like this commit [1] to be releases somehow.
>> I'll backport it to the 2.1 branch asap.
>>
>> [1] http://svn.apache.org/viewvc?view=rev&revision=615758
>>
>> On Thu, Sep 3, 2009 at 18:00, David Jencks <david_jencks@yahoo.com>  
>> wrote:
>>
>> On Sep 3, 2009, at 1:20 AM, Guillaume Nodet wrote:
>>
>>> A long time ago, I've made those two jars available as OSGi  
>>> bundles, but they haven't been released yet because I did that in  
>>> trunk.
>>> I'd really like to have those as bundles, so I can backport the  
>>> pom changes in the branch and release from the branch or release  
>>> trunk.
>>> Not sure what the exact status for this component is.  I've seen  
>>> djencks made some changes in the branch that are not available in  
>>> trunk, but trunk also has some changes.
>>
>> Can you be more specific about the changes and which svn urls you  
>> are talking about?
>>
>> https://svn.apache.org/repos/asf/geronimo/components/txmanager/ 
>> trunk  uses connector 1.6 spec, so I don't think we will release it  
>> until we have some idea that we are fairly OK with the ee6 tck, and  
>> also that it works with whatever osgi stuff we end up with in g.  
>> trunk.
>>
>> https://svn.apache.org/repos/asf/geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1

>>  uses connector 1.5 and we need to release it for g. 2.2 as it has  
>> some important bug fixes.
>>
>> Making sure both of these are osgi-workable would be great.  I  
>> thought I'd merged all the bug fixes both ways between these  
>> branches, if you see a problem please let me know!
>>
>> I'm hoping to get to releasing some specs and other sub-projects  
>> for 2.2 this week, so if you can make sure the 2.1 branch is  
>> acceptable that would be really great!
>>
>> thanks
>> david jencks
>>
>>
>>> Please advise what would be the best way to proceed here.
>>>
>>> -- 
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>
>>
>>
>>
>>
>> -- 
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>
>
>
>
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>


Mime
View raw message