Simple use of bundle plugin generates long list of bad Import-Package

[Benson Margulies <bi...@gmail.com>]

I am trying to wrap a maven artifact that depends on spring in a bundle, and
just make it self-contained.

I used pax to make a simple pom for the bundle plugin.

Eclipse throws up all over the results, because it has a giant
Import-Package list. It includes internal packages from the JVM, things that
are in the wrapped dependencies, you name it.

I have this feeling that I'm missing something awfully simple, but I don't
know what.

Re: Simple use of bundle plugin generates long list of bad Import-Package

[Benson Margulies <bi...@gmail.com>]

Thanks, I think this covers it.

On Thu, Feb 12, 2009 at 9:56 AM, Stuart McCulloch <mc...@gmail.com> wrote:

> 2009/2/12 Benson Margulies <bi...@gmail.com>
>
> > My seemingly simply goal was to take a library of mine with a (seemingly)
> > short list of dependencies, and turn it into a self-contained OSGi bundle
> > that would be comprehensible to the Eclipse IDE.
> >
> > The short list of dependencies includes Spring, and here I think is where
> I
> > got into trouble.
> >
> > I know that there are OSGi bundles for Spring, but, for this rather
> simple
> > exercise, I just wanted to put Spring inside my bundle, unexported.
> >
> > Spring appears to have a whole, complex, list of undeclared (from a Maven
> > standpoint) dependencies. Bnd+the bundle plugin thus produces a long list
> > of
> > Import-Packages for code that I don't actually need or want. cglib,
> jruby,
> > bsh, etc.
> >
>
> yes, these packages would be all referenced in the embedded bytecode
> and unless you tell it otherwise Bnd will assume they need to be imported
> (this is the safest default)
>
> Judging from some examples to I could find, this requires me to find all
> > these things and explicitly list them as Import-Package instructions with
> > the optional flag.
> >
>
> well, Bnd accepts wildcards so if you're wrapping a bundle and don't know
> what packages you actually need then you can use something like this:
>
>  <Import-Package>*;resolution:=optional</Import-Package>
>
> note that optional packages are only checked once - if the package isn't
> available at that time it won't be re-tested until your bundle is
> refreshed.
>
> if you want something more dynamic then use this:
>
>  <Dynamic-ImportPackage>*</Dynamic-ImportPackage>
>
> which will always check to see if the package is available on each request
> for a class from that package (until it is available, then it doesn't
> re-test)
>
> What I was hoping was some way to get the tools to omit or 'optional'
> > packages like this. Now, part of my problem is that I'm not clear on the
> > division of labor between bnd and maven-bundle-plugin
>
>
> see above - you can also explicity set the imported package list without
> wildcards.
>
> the bundleplugin maps the Maven classpath, resources, and Embed
> instructions
> into Bnd specific information and instructions which are passed to the Bnd
> Tool
> along with user instructions.
>
> the Bnd Tool takes the classpath and instructions and uses this to
> construct
> the
> bundle file, which it passes back to the bundleplugin to install in the
> local Maven
> repository, update the local OBR metadata, etc.
>
> so think of the bundleplugin as a Maven pre-(and post-)processor to the Bnd
> Tool
>
>
> > -- does bnd know the classpath so that it could put 'optional' on things
> > that are not on it?
> >
>
> the Bnd Tool is told about the classpath, but the available API does not
> support
> marking JARs as optional (also optionality usually makes sense per-package,
> not per-bundle/JAR - and you may have a package in more than one JAR)
>
> you can easily mark packages as optional (or exclude them with !) as shown
> before
>
> Peter's website (referred to from the bundleplugin docs:
> http://aqute.biz/Code/Bnd)
> has more detail and examples - as well as some on wrapping 3rd party
> libraries
>
> I can send you my various bits and pieces, but this might be enough to
> > clarify.
> >
>
> the pom (or at least any Bnd instructions from it) would be useful
>
> basically, when wrapping an initial bundle:
>
>   1) use a wildcard to mark all imports optional
>   2) embed the various runtime and compile-time dependencies*
>   3) use Private-Package / Export-Package to pull in locally compiled
> classes
>   4) use -exportcontents to tweak the final list of exported packages
>
> (*) another approach is to put them on the system classpath and use the
> "org.osgi.framework.system.packages.extra" property to add the various
> packages to the system bundle exports
>
> bear in mind that you might actually need those packages at runtime, so
> you may need to do further wrapping or embedding - I'll be talking more
> about this in the book I'm writing with Richard and Karl
>
> HTH
>
> On Thu, Feb 12, 2009 at 12:43 AM, Stuart McCulloch <mcculls@gmail.com
> >wrote:
> >
> > > 2009/2/12 Benson Margulies <bi...@gmail.com>
> > >
> > > > I am trying to wrap a maven artifact that depends on spring in a
> > bundle,
> > > > and
> > > > just make it self-contained.
> > > >
> > > > I used pax to make a simple pom for the bundle plugin.
> > > >
> > > > Eclipse throws up all over the results, because it has a giant
> > > > Import-Package list. It includes internal packages from the JVM,
> things
> > > > that
> > > > are in the wrapped dependencies, you name it.
> > > >
> > > > I have this feeling that I'm missing something awfully simple, but I
> > > don't
> > > > know what.
> > > >
> > >
> > > there is something missing...
> > >
> > > 1)  what command did you use to create the pom? (arguments, etc)
> > > 2)  what version of the maven-bundle-plugin are you using?
> > > 3)  did you modify the pom, and if so what did you change?
> > >     (or paste the full pom + Bnd instructions in your message)
> > > 4)  what combination of OS+Java+Maven are you using?
> > >
> > > note that if your wrapped dependencies do use non java.* packages
> > > from the JVM (for example com.sun...) then these will automatically
> > > be imported because they are referenced in the bytecode
> > >
> > > but from your brief description it sounds like you have an excessive
> > > wildcard somewhere in your Private-Package or Export-Package
> > > and that's pulling the entire classpath into your bundle.
> > >
> > > --
> > > Cheers, Stuart
> > >
> >
>
>
>
> --
> Cheers, Stuart
>

Re: Simple use of bundle plugin generates long list of bad Import-Package

[Stuart McCulloch <mc...@gmail.com>]

2009/2/12 Benson Margulies <bi...@gmail.com>

> My seemingly simply goal was to take a library of mine with a (seemingly)
> short list of dependencies, and turn it into a self-contained OSGi bundle
> that would be comprehensible to the Eclipse IDE.
>
> The short list of dependencies includes Spring, and here I think is where I
> got into trouble.
>
> I know that there are OSGi bundles for Spring, but, for this rather simple
> exercise, I just wanted to put Spring inside my bundle, unexported.
>
> Spring appears to have a whole, complex, list of undeclared (from a Maven
> standpoint) dependencies. Bnd+the bundle plugin thus produces a long list
> of
> Import-Packages for code that I don't actually need or want. cglib, jruby,
> bsh, etc.
>

yes, these packages would be all referenced in the embedded bytecode
and unless you tell it otherwise Bnd will assume they need to be imported
(this is the safest default)

Judging from some examples to I could find, this requires me to find all
> these things and explicitly list them as Import-Package instructions with
> the optional flag.
>

well, Bnd accepts wildcards so if you're wrapping a bundle and don't know
what packages you actually need then you can use something like this:

  <Import-Package>*;resolution:=optional</Import-Package>

note that optional packages are only checked once - if the package isn't
available at that time it won't be re-tested until your bundle is refreshed.

if you want something more dynamic then use this:

  <Dynamic-ImportPackage>*</Dynamic-ImportPackage>

which will always check to see if the package is available on each request
for a class from that package (until it is available, then it doesn't
re-test)

What I was hoping was some way to get the tools to omit or 'optional'
> packages like this. Now, part of my problem is that I'm not clear on the
> division of labor between bnd and maven-bundle-plugin


see above - you can also explicity set the imported package list without
wildcards.

the bundleplugin maps the Maven classpath, resources, and Embed instructions
into Bnd specific information and instructions which are passed to the Bnd
Tool
along with user instructions.

the Bnd Tool takes the classpath and instructions and uses this to construct
the
bundle file, which it passes back to the bundleplugin to install in the
local Maven
repository, update the local OBR metadata, etc.

so think of the bundleplugin as a Maven pre-(and post-)processor to the Bnd
Tool


> -- does bnd know the classpath so that it could put 'optional' on things
> that are not on it?
>

the Bnd Tool is told about the classpath, but the available API does not
support
marking JARs as optional (also optionality usually makes sense per-package,
not per-bundle/JAR - and you may have a package in more than one JAR)

you can easily mark packages as optional (or exclude them with !) as shown
before

Peter's website (referred to from the bundleplugin docs:
http://aqute.biz/Code/Bnd)
has more detail and examples - as well as some on wrapping 3rd party
libraries

I can send you my various bits and pieces, but this might be enough to
> clarify.
>

the pom (or at least any Bnd instructions from it) would be useful

basically, when wrapping an initial bundle:

   1) use a wildcard to mark all imports optional
   2) embed the various runtime and compile-time dependencies*
   3) use Private-Package / Export-Package to pull in locally compiled
classes
   4) use -exportcontents to tweak the final list of exported packages

(*) another approach is to put them on the system classpath and use the
"org.osgi.framework.system.packages.extra" property to add the various
packages to the system bundle exports

bear in mind that you might actually need those packages at runtime, so
you may need to do further wrapping or embedding - I'll be talking more
about this in the book I'm writing with Richard and Karl

HTH

On Thu, Feb 12, 2009 at 12:43 AM, Stuart McCulloch <mc...@gmail.com>wrote:
>
> > 2009/2/12 Benson Margulies <bi...@gmail.com>
> >
> > > I am trying to wrap a maven artifact that depends on spring in a
> bundle,
> > > and
> > > just make it self-contained.
> > >
> > > I used pax to make a simple pom for the bundle plugin.
> > >
> > > Eclipse throws up all over the results, because it has a giant
> > > Import-Package list. It includes internal packages from the JVM, things
> > > that
> > > are in the wrapped dependencies, you name it.
> > >
> > > I have this feeling that I'm missing something awfully simple, but I
> > don't
> > > know what.
> > >
> >
> > there is something missing...
> >
> > 1)  what command did you use to create the pom? (arguments, etc)
> > 2)  what version of the maven-bundle-plugin are you using?
> > 3)  did you modify the pom, and if so what did you change?
> >     (or paste the full pom + Bnd instructions in your message)
> > 4)  what combination of OS+Java+Maven are you using?
> >
> > note that if your wrapped dependencies do use non java.* packages
> > from the JVM (for example com.sun...) then these will automatically
> > be imported because they are referenced in the bytecode
> >
> > but from your brief description it sounds like you have an excessive
> > wildcard somewhere in your Private-Package or Export-Package
> > and that's pulling the entire classpath into your bundle.
> >
> > --
> > Cheers, Stuart
> >
>



-- 
Cheers, Stuart

Re: Simple use of bundle plugin generates long list of bad Import-Package

[Benson Margulies <bi...@gmail.com>]

My seemingly simply goal was to take a library of mine with a (seemingly)
short list of dependencies, and turn it into a self-contained OSGi bundle
that would be comprehensible to the Eclipse IDE.

The short list of dependencies includes Spring, and here I think is where I
got into trouble.

I know that there are OSGi bundles for Spring, but, for this rather simple
exercise, I just wanted to put Spring inside my bundle, unexported.

Spring appears to have a whole, complex, list of undeclared (from a Maven
standpoint) dependencies. Bnd+the bundle plugin thus produces a long list of
Import-Packages for code that I don't actually need or want. cglib, jruby,
bsh, etc.

Judging from some examples to I could find, this requires me to find all
these things and explicitly list them as Import-Package instructions with
the optional flag.

What I was hoping was some way to get the tools to omit or 'optional'
packages like this. Now, part of my problem is that I'm not clear on the
division of labor between bnd and maven-bundle-plugin -- does bnd know the
classpath so that it could put 'optional' on things that are not on it?

I can send you my various bits and pieces, but this might be enough to
clarify.


On Thu, Feb 12, 2009 at 12:43 AM, Stuart McCulloch <mc...@gmail.com>wrote:

> 2009/2/12 Benson Margulies <bi...@gmail.com>
>
> > I am trying to wrap a maven artifact that depends on spring in a bundle,
> > and
> > just make it self-contained.
> >
> > I used pax to make a simple pom for the bundle plugin.
> >
> > Eclipse throws up all over the results, because it has a giant
> > Import-Package list. It includes internal packages from the JVM, things
> > that
> > are in the wrapped dependencies, you name it.
> >
> > I have this feeling that I'm missing something awfully simple, but I
> don't
> > know what.
> >
>
> there is something missing...
>
> 1)  what command did you use to create the pom? (arguments, etc)
> 2)  what version of the maven-bundle-plugin are you using?
> 3)  did you modify the pom, and if so what did you change?
>     (or paste the full pom + Bnd instructions in your message)
> 4)  what combination of OS+Java+Maven are you using?
>
> note that if your wrapped dependencies do use non java.* packages
> from the JVM (for example com.sun...) then these will automatically
> be imported because they are referenced in the bytecode
>
> but from your brief description it sounds like you have an excessive
> wildcard somewhere in your Private-Package or Export-Package
> and that's pulling the entire classpath into your bundle.
>
> --
> Cheers, Stuart
>

Re: Simple use of bundle plugin generates long list of bad Import-Package

[Stuart McCulloch <mc...@gmail.com>]

2009/2/12 Benson Margulies <bi...@gmail.com>

> I am trying to wrap a maven artifact that depends on spring in a bundle,
> and
> just make it self-contained.
>
> I used pax to make a simple pom for the bundle plugin.
>
> Eclipse throws up all over the results, because it has a giant
> Import-Package list. It includes internal packages from the JVM, things
> that
> are in the wrapped dependencies, you name it.
>
> I have this feeling that I'm missing something awfully simple, but I don't
> know what.
>

there is something missing...

1)  what command did you use to create the pom? (arguments, etc)
2)  what version of the maven-bundle-plugin are you using?
3)  did you modify the pom, and if so what did you change?
     (or paste the full pom + Bnd instructions in your message)
4)  what combination of OS+Java+Maven are you using?

note that if your wrapped dependencies do use non java.* packages
from the JVM (for example com.sun...) then these will automatically
be imported because they are referenced in the bytecode

but from your brief description it sounds like you have an excessive
wildcard somewhere in your Private-Package or Export-Package
and that's pulling the entire classpath into your bundle.

-- 
Cheers, Stuart