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
<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
Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@oracle.com
P.S. A good JDO? O, Gasp!
