Improve warning for optional Imports w/o version

[chrisrueger]

This is an attempt / idea to improve the pedantic warning "Imports that lack version ranges" .

[chrisrueger]

Just for me:

I observed the following:

Assume:

• I have some direct dependency which requires com.fasterxml.jackson.annotation (direct dep is org.mustangproject:library which I am using via -includeresource; lib:=true because it is not an OSGi bundle )
• I only do in bnd.bnd: Import-Package: *

Then I get:

Imports that lack version ranges [com.fasterxml.jackson.annotation]

and the MANIFEST.MF only contains:

Import-Package                          com.fasterxml.jackson.annotation

But I actually have com.fasterxml.jackson.core.jackson-annotations;version=2.18.3 in my Repository.

Now I add the jackson lib to my buildpath:

-buildpath: \
   com.fasterxml.jackson.core.jackson-annotations;version=2.18.3

or even

-buildpath: \
   com.fasterxml.jackson.core.jackson-annotations;version=latest

(Even though my own code in the bundle does NOT use com.fasterxml.jackson.core.jackson-annotations directly)

Then MANIFEST.MF contains the version:

Import-Package                          com.fasterxml.jackson.annotation;version="[2.18,3)"

I wonder if this is the way it is supposed to work.
I guess, me putting it in -builtpath gives bnd a more explicit hint.
But why can't bnd do the same without it being on the buildpath?

[chrisrueger]

I asked chatGPT and I believe the answer is correct. Thus I am closing the PR now.

---

Why It Works When You Add It to the Buildpath

When you do:

-buildpath: \
   com.fasterxml.jackson.core.jackson-annotations;version=2.18.3

Then Bnd can analyze the actual JAR and read version information from either:

• packageinfo files
• Export-Package headers from the JAR’s manifest

Hence, Bnd can now generate:

Import-Package: com.fasterxml.jackson.annotation;version="[2.18,3)"

So the warning disappears because the version range is now known.

Why Doesn't Bnd Do It Automatically If It's in the Repository?

This is the crux of your question.

"Why can't Bnd just use the Repository to figure out the version?"

Because Bnd separates two concerns:

1. Compilation/building (-buildpath)
2. Resolution/assembly (-runbundles, -runpath, -runrequires, etc.)

Just because a JAR is in your repository does not mean Bnd will include or inspect it unless you explicitly declare its usage:

• On the -buildpath (so it's available to compile against), or

Bnd never introspects the repository just in case something might be needed — that would introduce unpredictable behavior and unnecessary coupling.

---

After thinking about it this way I think it makes sense. Closing.

[kriegfrj]

But why can't bnd do the same without it being on the buildpath?

Although ChatGPT gave you a general answer, a specific example could be: what is you have two versions of the dependency in your workspace? Which version range should it use (especially if they have different major versions)?

I'm curious though: Bnd is smart enough to include imports for transitive dependencies that are required at runtime but not in the build path. But if you're building with proper bundles as your buildpath artifacts, then those transitive dependencies should be listed in one of those bundles' import package statements, which should have the correct version range, which Bnd will then use.

If I'm correct, then I'm guessing that your buildpath had a jar on it that either wasn't a bundle, was missing the import package for the annotation package, or was missing the import range for the transitive package?

[chrisrueger]

If I'm correct, then I'm guessing that your buildpath had a jar on it that either wasn't a bundle, was missing the import package for the annotation package, or was missing the import range for the transitive package?

Yes I think you are correct.
We have a non-OSGi Bundle (https://mvnrepository.com/artifact/org.mustangproject/library/2.17.0) included via -includeresource ;lib:=true in our bundle

• this internally / transitively needs com.fasterxml.jackson which leads to the Import-Package without version
• since this is a non-OSGi bundle, there are no version information there

It makes sense now.
I realize that I am often stumble over this kind of stuff although working with bnd / OSGi for some time. My bad. My brain has no OSGi-resolver yet ;)
Not sure if there is anything which could be done here, other than maybe enriching the UI or some warnings with exactly this educative information we are discussing here.

[chrisrueger]

@kriegfrj I reopened the PR and changed it so that I just add an explanation to the warning.
What do you think? Would you explain it different?