Using -noimport with @Export annotation

GENERAL
1

I want to use the @Export annotation in a project but BND als generates a corresponding import.

Because the OSGi Spec suggest:

“In practice, importing exported packages can only be done with clean API-implementation separation.”

So the question is how to disable this without an Export-Package header in the BND file?

2

Well, read the documentation of the @Export :slight_smile: (I always love it when I can say this!)

The @Export annotation has a substitution method. There you can set the rules for the substitution: CONSUMER, PRODUCER, NOIMPORT, and CALCULATED. The last one is the default and bnd does a good job of that.

So you can do:

@Export(substitution=Substitution.NOIMPORT)

That said, it is in all cases I am aware of not good practice. The bnd calculation is very good and there are very few cases where you need to override it. Package substitution is one of the cornerstones of OSGi.

I’d be interested to know why you need this.

3

I’m glad I can make you happy :slight_smile:

It is a bit unclear what this means and I assumed I can somehow influence it by a setting, e.g. how do BND calculates “clean API-implementation separation” (I can tell for my example it is most likely NOT clean separation…) from experiments with that is that BND simply always exports the package, and I like to disable this instead of hard coding this on every export annotation and more explicitly enable it on demand :sweat_smile:

That’s something state here and there but for > 10 years I never found any real use for it except for the case where an bundle also includes foreign(!) API packages (that is something I generally avoid), so the question is more why should I ever want this?

4
  1. bnd will not import the package if this would become unsafe or there is no need to. A pure API that is not referenced inside the bundle will, for example, not be imported
  2. Packages are imported with different ranges based on their consumer/provider role. There is quite a lot of theory behind this.

It gives the runtime more leeway to wire up bundles. If you do not allow this you increase the number of times you get unresolveable systems and/or multiple class spaces in the runtime. You just make the runtime much more complex by removing many compatible constellations.

It is of course your choice, but unless you got very messy packages and you know exactly what you’re doing, I think you just safe yourself a lot of misery using calculate :slight_smile:

I am curious, did you experience actual problems with this or just suspicious it might not work? :slight_smile:

Anyway, you can also control the exports with the Export-Package instruction in the bnd file, you can then add the -noimport:=true directive and use wildcards but that will probably not work very well with the @Export annotation. I do not think there is a global flag for this and a I can’t find it with a quick search. Since the default CALCULATE works so well, I guess there never was a need for such control.

5

But it also gives harder times to debug things, and I suspect most of the time no one really will use substitution packages, e.g. just the usual “add OSGi headers to this library please” no one will really ever want to provide an alternative package variant.

Yep that’s why I wanted to to switch to @Export annotation

It depends on what what one qualifies as an “issue”, from a technical POV this all will work but:

  1. If I add OSGi metadata to a library, I most often try to find the smallest possible increment, that is, the less I add compared to the current library state, the more likely it is that my change will be accepted by a maintainer knowing not much about OSGi
  2. Enabling features (here package substitution) for there is no real need (e.g most of the time no one really likes to substitute anything) always have the risk of adding complexity or maybe side-effects hard to understand, so less features are generally better in terms of maintaining by a non OSGi-Expert

So these are more soft-facts than hard technical issues, but often it is better to have less sophisticated support than full-fledged support that makes people feel it is “to complex” for a library that is not primarily used in OSGi and maintained by people with zero knowledge about all the fancy stuff from OSGi.

6

Well, it is up to you but imho not using the defaults will cause more pain in the long run than you trying to be cleverer than bnd and its 23 year history in these matters. But you won’t be the first one if that comforts you :slight_smile: