Hi Craig, Yep, this is precisely the stuff I want to add - I've been using the maven-bundle-plugin and like it a lot. I'll update the poms shortly and we can review.
A quick question though - I noticed in the example you gave that version numbers are not specified on the export or import package entries. AIUI, this is a OSGi best practice to avoid version discrepancies since not specifying an Import-Package version is technically the same as saying version=[0.0.0, infinity). Is there a specific reason why the project you pasted from does not do this? (I'm always trying to ensure my bundles are as 'proper' as they can be, since OSGi versioning can be a nasty, nasty business - if I'm missing something, I'm open to suggestions!) Thanks, Les. On Wed, Sep 8, 2010 at 7:16 PM, Craig L Russell <craig.russ...@oracle.com> wrote: > Hi Les, > > Take a look at the plugins that make jars into OSGi jars just by a bit of > metadata. > > I've no objection if you add stuff like: > > <plugin> > <groupId>org.apache.felix</groupId> > <artifactId>maven-bundle-plugin</artifactId> > <version>1.4.0</version> > <extensions>true</extensions> > <configuration> > <instructions> > <Export-Package>com.mysql.clusterj.tie.*</Export-Package> > > <Import-Package>com.mysql.clusterj,com.mysql.clusterj.core.store,com.mysql.clusterj.core.query,com.mysql.clusterj.core.util,com.mysql.ndbjtie.mysql,com.mysql.ndbjtie.ndbapi</Import-Package> > </instructions> > </configuration> > </plugin> > > It's no bother to anyone not using OSGi and a huge help to people using it. > > Plus, it increases the use of "Apache uses Apache". > > Craig > > On Sep 8, 2010, at 6:54 PM, Les Hazlewood wrote: > >> Hi team, >> >> I'm writing an OSGi-based application, and I need the Shiro jars to >> also be OSGi bundles. Does anyone have any objections with me adding >> the OSGi metadata to the Manifest files? This would require changes >> only to poms - not source code. It is 100% backwards compatible. >> >> This is what I would consider an interim step in making Shiro fully >> OSGi friendly. I think a more 'proper'/full OSGi approach would be >> better suited for a Shiro 2.0 distribution since it would likely >> require re-organizing some packages. This would be close to the >> _very_ old JSecurity 0.1 days, where there was an API jar and >> implementation jars. It is sort of similar to how the existing >> 'support' modules work today, but there would be segmentation in the >> core module itself. But of course, this type of work is further down >> the line - like I said, a good candidate for 2.x work. >> >> For now, I'd like to just get the metadata in the existing .jars. Any >> objections? >> >> Cheers, >> >> Les
