fix: jaxrs-ri import-package on org.glassfish.hk2.osgiresourcelocator

[jkevan]

Refer to issue: #5946

Where import-package for org.glassfish.hk2.osgiresourcelocator doesn't seem's correct, it's catched by the global import: ${hk2.osgi.version} which resolve to: <hk2.osgi.version>org.glassfish.hk2.*;version="[2.5,4)"</hk2.osgi.version>.

But osgiresourcelocator is not following other org.glassfish.hk2.* versioning.

One jaxrs-ri repackaged bundle: jersey-commons:2.47 is using 1.x version of osgiresourcelocator

<dependency>
                <groupId>org.glassfish.hk2</groupId>
                <artifactId>osgi-resource-locator</artifactId>
                <version>1.0.3</version>
            </dependency>

[senivam]

Could you please rebase your PR on top of the current 2.x? It's updated. And re-push the PR. This will fix the copyright issue. Thank you.

[jkevan]

Just rebased !

I have a question regarding the jaxrs-ri bundle's configuration: Is it intentional that the bundle includes Import-Package declarations for its own repackaged components?

For example, most org.glassfish.jersey.* packages have Import-Package clauses in the MANIFEST.MF:

org.glassfish.jersey.message           {version=[2.47,3)}
org.glassfish.jersey.message.internal  {version=[2.47,3)}
org.glassfish.jersey.model             {version=[2.47,3)}
org.glassfish.jersey.model.internal    {version=[2.47,3)}
org.glassfish.jersey.model.internal.spi {version=[2.47,3)}
org.glassfish.jersey.process           {version=[2.47,3)}
org.glassfish.jersey.process.internal  {version=[2.47,3)}
org.glassfish.jersey.server            {version=[2.47,3)}
org.glassfish.jersey.server.filter     {version=[2.47,3)}

Since these packages are normally provided by the jaxrs-ri bundle itself, having Import-Package declarations for them could potentially create conflicts if multiple bundles provide the same packages within the same OSGi container. But it can also considered to be a desired behavior, by importing exported packages it's making those repackaged packages substitutable and the OSGI framework will decide which one to use depending on the multiple versions available.

Context for this question:

• If this behavior is intentional, then my current PR addresses the right issue
• If it's not intentional, my PR may be unnecessary, and I could interesting to submit a different PR to clean up the unneeded Import-Package declarations for all self-contained repackaged Java packages.

Additional information:
We're successfully using this bundle in a Karaf ecosystem, and we greatly appreciate your maintenance efforts! On our end, we're repackaging the jaxrs-ri bundle with additional components, and we've decided to remove all Import-Package declarations related to classes/packages contained within our repackaging to ensure full control and no conflict at runtime.

Best regards.

[jansupol]

@jkevan The jersey bundles are prebuilt for easy grab-and-deploy operation to be used with Tomcat or some other container. I am not aware of a case where the bundle is being used in an OSGi environment. The automatic creation of the OSGi can be wrong.

How did you find the error? Do you have an OSGi environment to run the bundle?

The self-import of the packages is indeed not correct. Feel free to update the PR with updated OSGi plugin directives that work well in your environment.