I've committed all changes to the trunk (pom.xml changes only) - all library .jars (core, 3rd party support) have been made into OSGi bundles. I didn't spend any time adding OSGi metadata to the samples modules since no one would use those as a dependency. Please update and take a peek if you're interested.
One issue: I did not add any OSGi metadata to the shiro-all aggregate .jar. Should we do this? My assumption is that most people who are deploying OSGi applications, given OSGi's inclination towards modularity, wouldn't deploy the shiro-all .jar. Does anyone have opinions on this one? Les On Wed, Sep 8, 2010 at 10:21 PM, Craig L Russell <[email protected]> wrote: > Hi Les, > > On Sep 8, 2010, at 7:40 PM, Les Hazlewood wrote: > >> 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!) > > I'm afraid I'm not an expert on OSGi, so hopefully someone else can chime in > with an opinion. > > Craig >> >> Thanks, >> >> Les. >> >> On Wed, Sep 8, 2010 at 7:16 PM, Craig L Russell >> <[email protected]> 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 > > Craig L Russell > Architect, Oracle > http://db.apache.org/jdo > 408 276-5638 mailto:[email protected] > P.S. A good JDO? O, Gasp! > >
