Wrapping/repackaging dependencies in bnd-maven-plugin

[Simon Chemouil]

Hi,

I am building a bundle with bnd-maven-plugin that's using a dependency that's not packaged as a bundle the way I want.

I'd first like to repackage this dependency (e.g, restraining the range of some of its import statements) without having to fork it and maintain a fork, but rather by using maven to wrap it a bit like what Embed-Dependency allows to do in maven-bundle-plugin.

Ideally, I'd like to repackage that dependency without having to create a separate project, but directly from my own bundle that has some extra stuff (e.g defining declarative components).

I'm not sure how to go at this without resorting to heavy artillery (maven-dependency-plugin & playing with execution phases ...). Is there any straightforward way and how would you guys advise going at it?

Any pointers appreciated!

Thanks,

Simon

[Raymond Auge]

It's pretty simple actually. No extra plugins required. But be careful as you can easily shoot yourself in the foot. Some of these operations don't work well together in the wrong
combination.

But these are good combinations:

Add the dependency to the maven project as usual.

There are a bunch of ways to absorb such third party jars depending on what you wish to do with the packages:

1. You wish to both include package X and export it

Just use

Export-Package: X

and the package will both be absorbed from the compile classpath (buildpath in bnd speak) into your bundle, and exported at the known range. If no version is available on the package you can include a version attribute of your own.

Export-Package: X;version='1.2.3'

Done! That's all you need.

2. You wish to embed the package without exporting it

Just use

Conditional-Package: X

and the package will be absorbed from the compile classpath (buildpath in bnd speak) into your bundle.

Done!

3. You wish to embed specific classes because the packages is terrible and you need to constrain what gets included (i.e. monolith packages)

Use

-includeresource: @x-*.jar!/com/foo/SomeClass*.jar

This absorbs just specific class (add more lines to include more, or expand the glob, oh and remember to include the glob on the class in case it has inner classes).

Oh, and you wish to also export the package now?

-exportcontents: X;version='1.2.3'

this will only export the content of the package as you have created it in your bundle.

4. You wish to embed the whole jar, put it on the Bundle-ClassPath because you need multiple libraries to make it work and they also have common resources which you don't want to break (ugh...)

Use

-includeresource: lib/x.jar=x-*.jar;lib:=true

This says; find the library x-*.jar (globing really works) on the [build/class]path, place it in the bundle at /lib/x.jar, Oh and also append it to the Bundle-ClassPath (adding the Bundle-ClassPath header with appropriate default if it's not already there).

Oh, and you want to export one of the packages from the Bundle-ClassPath jars?

-exportcontents: X;version='1.2.3'

HTH,

- Ray

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)

Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)

[Simon Chemouil]

Thanks Ray! Works perfectly.

Simon

To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.