Thanks, I think this covers it. On Thu, Feb 12, 2009 at 9:56 AM, Stuart McCulloch <[email protected]> wrote:
> 2009/2/12 Benson Margulies <[email protected]> > > > 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 <[email protected] > >wrote: > > > > > 2009/2/12 Benson Margulies <[email protected]> > > > > > > > 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 >
