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:
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.
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.
On Thu, Sep 3, 2009 at 19:04, David Jencks <firstname.lastname@example.org>
I thought I had already bundleized 2.1.... since we are using the 2.0.0 bundle plugin a direct merge or  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?
On Sep 3, 2009, at 9:18 AM, Guillaume Nodet wrote:
I'd like this commit  to be releases somehow.
I'll backport it to the 2.1 branch asap.
On Thu, Sep 3, 2009 at 18:00, David Jencks <email@example.com>
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?
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!
Open Source SOA
Open Source SOA