Maven-bundle-plugin observations

["Hampel, Michael" <mi...@siemens.com>]

Hello,
 
after working a while now with the maven-bundle-plugin I would like to
share some 
observations and ask questions about them.
 
I am using the plugin in my poms for running to goals: manifest and
bundle.
In certain cases these two goals produce two different MANIFEST.MF files
as regards context.
 
In the first case I have the following bundle structure:
 
Bundle A defines certain interfaces and exports them in a package
org.a.messaging.
Bundle B implements these interfaces and reexports them, so it imports
org.a.messaging and exports
org.a.messaging. The implementation classes in org.b.messaging.internal
are kept "private" - not exported.
If I have a maven-bundle plugin configuration for Bundle B that looks
like this:
 
        <instructions>
          <Export-Package>org.a.messaging</Export-Package>
        </instructions>
 
the manifest goal will create the following MANIFEST.MF file(excerpt):
    
        .......
        Private-Package: org.b.messaging.internal
        Import-Package: org.a.messaging, (plus all other import
packages)
       .......
 
The main problem is that their is no Export-Package entry in the
generated MANIFEST.MF file.
 
The bundle goal on the other hand will generate the following
MANIFEST.MF file(excerpt):
 
        ......
        Export-Package: org.a.messaging
        Import-Package:  org.a.messaging, (additional import packages
are MISSING!!)
        .....
 
Here I don't get a Private-Package entry and I am missing several Import
packages which are in the
MANIFEST.MF file generated by the manifest goal - but I have an
Export-Package entry:)
The missing imported packages are referenced in the
org.b.messaging.internal package classes.
 
What I did then - I added a Private-Package instruction to the pom of
Bundle B:
 
        <instructions> 
          <Export-Package>org.a.messaging</Export-Package>
          <Private-Package>org.b.messaging.internal.*</Private-Package>
        </instructions>
 
This did not change anything for the manifest goal - still no
Export-Package entry in the MANIFEST.MF
file - all other entries stayed the same.
 
The bundle goal on the other hand now created the following MANIFEST.MF
file:
 
        ...... 
        Export-Package: org.a.messaging
        Private-Package: org.b.messaging.internal
        Import-Package:  org.a.messaging, plus additional import
packages
        .....
 
So with this configuration I got the MANIFEST.MF file I wanted - with
all necessary entries.
 
Is it necessary to state Private-Packages in contrast to only using the
Export-Package instruction?
 
Another example is, if I have a bundle that has a BundleActivator class
that is NOT in an exported package.
The manifest goal will succeed and put the Activator in the MANIFEST.MF
file.
The bundle goal on the other side will fail with an Exception and
complains about that the Activator class is not found
on the classpath or any imported package.
As I don't know which behaviour is the correct one regarding the OSGi
spec (can I have a BundleActivator
in a non exported package?), in the moment I exported the package.
Are these two goals using different classpaths?
 
Sorry for this long post and that I had no time to look deeper in the
maven-bundle-plugin implementation to find
the reasons for the above mentioned behaviour - but I thought maybe this
is interesting for others as well.
 
Thanx in advance for any help and answers,
 
michael
 
 

Re: Maven-bundle-plugin observations

[Niclas Hedhman <ni...@hedhman.org>]

On Monday 02 July 2007 16:58, Hampel, Michael wrote:
> Sorry for this long post and that I had no time to look deeper in the
> maven-bundle-plugin implementation to find
> the reasons for the above mentioned behaviour

I think you don't get much response to this post due to the discussion 
around "manifest" vs "bundle" goals. AFAIK, most people wouldn't know one 
from the other and just set <packaging>bundle</packaging> and then run "mvn 
install".

I think it is better you provide a small setup where you have all the bits and 
pieces in place, so people can look at the details instead of second-guessing 
your explanation and assumptions, that are not easily verifiable.

Cheers
Niclas