Bnd and using Dynamic-ImportPackage instead of resolution:=optional

[Simon Chemouil]

Hi,

I'd like to have some optional packages dynamically imported, but with a bnd computed version range + classpath packages expansion to ensure proper compatibility.

With resolution:=optional it's simple, bnd computes the version range from the MANIFEST of the classpath JAR I'm building against.

Is there any way to convert a bunch of optional packages present on the classpath (e.g org.foo.bar and org.foo.bar.*) to dynamic-ImportPackages? The goal is to avoid the need to order resolution or refresh.

Thanks,

Simon

[Simon Chemouil]

I meant DynamicImport-Package of course :)

Bnd doesn't seem to be post-processing the header.

[BJ Hargrave]

When you dynamically import packages, you generally are not picky about the package version. You dynamically import because someone else told you the class name to load. Generally your code will not have a strong dependency on the version of the package that class came in since you wont be using that type directly in your code. For example, you get the name of some codec class, you need to load the class but you may only refer to it by a super type which you have a normal package import for. This is why Bnd does not add version information to DIP.

--
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-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

BJ

[Simon Chemouil]

Le mercredi 10 mai 2017 23:24:49 UTC+2, BJ Hargrave a écrit :

When you dynamically import packages, you generally are not picky about the package version. You dynamically import because someone else told you the class name to load. Generally your code will not have a strong dependency on the version of the package that class came in since you wont be using that type directly in your code. For example, you get the name of some codec class, you need to load the class but you may only refer to it by a super type which you have a normal package import for. This is why Bnd does not add version information to DIP.

Yes, I know that's the main reason DIP was introduced (e.g Hibernate). But it can also be used to handle optional packages without requiring a refresh, since wires can be added after resolution, once a suitable class is found. There's a pretty cool blog post[1] about that. In the recent thread by Ray Augé on osgi-dev@, Tim Ward suggested[2] using DIPs + a BundleListener for that kind of dynamic optional package handling, so I guess it's a valid use case. Having bnd support for that would be nice. If there isn't, I will have to do it by hand. It could be solved without explicit support by a macro to get a package version and a macro to expand packages on the classpath matching a pattern.

Simon

[1] http://web.ist.utl.pt/ist162500/?p=65#Optional_Imports_VS_Dynamic_Imports

[2] https://www.mail-archive.com/osgi...@mail.osgi.org/msg05213.html

[BJ Hargrave]

There are macros like ${packageattribute;com.foo;version} but they only work on packages contained in the bundle being built. They don't tell you about packages on the -buildpath.

Perhaps what you need it a post processing step which moves a set of packages from IP to DIP?

--

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-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

BJ

[Simon Chemouil]

Le mercredi 10 mai 2017 23:44:06 UTC+2, BJ Hargrave a écrit :

There are macros like ${packageattribute;com.foo;version} but they only work on packages contained in the bundle being built. They don't tell you about packages on the -buildpath.

Perhaps what you need it a post processing step which moves a set of packages from IP to DIP?

Yes a bnd plugin adding pre-processing for certain packages would be a nice way to do this, since otherwise those packages have to be explicitly excluded from Import-Package. I might have a go at it if it reaches a higher priority on my todo list ;). First I wanted to confirm bnd does not currently support a way to do this... mere mortals like me can never know which miracles bnd is capable of through exotic combinations of features and other undocumented marvels ;)

Thanks,

Simon

[Peter Kriens]

The easiest way to add this to bnd is to start processing the DIP header. Additionally, a macro could be added to Project that took a list like Import-Package takes and process it in the same way. 

I think you can probably do it in bnd with macros as is but it will be ugly as hell :-)

Kind regards,

Peter Kriens

[Simon Chemouil]

Hi,

Would such a pull request be accepted in bnd 3.4?

Simon

[BJ Hargrave]

It may be best to model dynamic imported packages as resolution:=dynamic which is how OSGi models them in the osgi.wiring.package namespace. Then for the manifest, the resolution:=dynamic packages are in DIP rather than IP. This will allow all the logic for imported packages to just "work" since they just have a different resolution than mandatory or optional. Devs can just add resolution:=dynamic to the packages in the bnd's files IP statement and there is no need to put a DIP statement in the bnd file. If there is a DIP in the bnd file, Bnd should add any resolution:=dynamic package from the IP statement to the specified DIP.

Also the PR must come with a set of new tests!

We are trying to close down 3.4 now. If you can make a good PR in short order, we can include it but of course there are no guarantees.

--
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-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

BJ

[Simon Chemouil]

Le jeudi 11 mai 2017 16:00:14 UTC+2, BJ Hargrave a écrit :

It may be best to model dynamic imported packages as resolution:=dynamic which is how OSGi models them in the osgi.wiring.package namespace. Then for the manifest, the resolution:=dynamic packages are in DIP rather than IP. This will allow all the logic for imported packages to just "work" since they just have a different resolution than mandatory or optional. Devs can just add resolution:=dynamic to the packages in the bnd's files IP statement and there is no need to put a DIP statement in the bnd file. If there is a DIP in the bnd file, Bnd should add any resolution:=dynamic package from the IP statement to the specified DIP.

Also the PR must come with a set of new tests!

We are trying to close down 3.4 now. If you can make a good PR in short order, we can include it but of course there are no guarantees.

I was also thinking of using resolution:=dynamic (even though I was not aware it was the way it was modeled at runtime, but because it was practical and elegant) and in general planning to do what you describe. I found a way to make it work with a plugin, but if it can be included upstream all the better. So: https://github.com/bndtools/bnd/pull/2039

Simon