Missing Constraints when using Milo as bundle in OSGi context

[m-meingast]

Describe the bug
When using the org.eclipse.milo.milo-sdk-client Maven artifact as a bundle in an OSGi context there are Missing Constraint errors due to imported packages in the MANIFEST.MF:

org.eclipse.milo.stack-core:
    Missing Constraint: Import-Package: sun.security.provider.certpath; version="0.0.0"

org.eclipse.milo.sdk-client:
    Missing Constraint: Import-Package: org.eclipse.milo.shaded.com.google.common.collect; version="0.0.0"

The error with the sun.security.provider.certpath package has already been fixed a while ago with #1175, but the changes were dropped with the 1.0.0 release.

For the second error I looked through the MANIFEST.MF files of sdk-client and stack-core. sdk-client wants to import org.eclipse.milo.shaded.com.google.common.collect, but stack-core only exports com.google.common.collect. I've read into it and it seems that the maven-bundle-plugin writes the MANIFEST.MF file before the maven-shade-plugin creates the milo.shaded package, leading to the shaded package not beeing written into the manifest.

Expected behavior
No error should occur when using Milo in an OSGi context.

Additional context
Eclipse Milo version: 1.1.0

[kevinherron]

I coerced an LLM into producing this maven-bundle-plugin configuration as a fix for your 2nd issue (applied to opc-ua-stack/stack-core/pom.xml):

  <plugin>
    <groupId>org.apache.felix</groupId>
    <artifactId>maven-bundle-plugin</artifactId>
    <configuration>
      <instructions>
        <!-- Export the shaded Guava packages for OSGi.
             The maven-bundle-plugin runs before maven-shade-plugin, so it doesn't
             see the relocated packages. We explicitly declare them here using
             _exportcontents which adds exports without copying classes. -->
        <_exportcontents>
          org.eclipse.milo.shaded.com.google.common.*;version="${project.version}"
        </_exportcontents>
      </instructions>
    </configuration>
  </plugin>

Knowing nothing about OSGi nor having access to an OSGi environment, you'll have to tell me if this is valid or not.

edit: this didn't seem to work, the manifest didn't have this entry. I think the lifecycle/phase is wrong.

[m-meingast]

I coerced an LLM into producing this maven-bundle-plugin configuration as a fix for your 2nd issue (applied to opc-ua-stack/stack-core/pom.xml):

  <plugin>
    <groupId>org.apache.felix</groupId>
    <artifactId>maven-bundle-plugin</artifactId>
    <configuration>
      <instructions>
        <!-- Export the shaded Guava packages for OSGi.
             The maven-bundle-plugin runs before maven-shade-plugin, so it doesn't
             see the relocated packages. We explicitly declare them here using
             _exportcontents which adds exports without copying classes. -->
        <_exportcontents>
          org.eclipse.milo.shaded.com.google.common.*;version="${project.version}"
        </_exportcontents>
      </instructions>
    </configuration>
  </plugin>

Knowing nothing about OSGi nor having access to an OSGi environment, you'll have to tell me if this is valid or not.

edit: this didn't seem to work, the manifest didn't have this entry. I think the lifecycle/phase is wrong.

Thank you for the swift response. I actually tried the exact same thing in the pom.xml of stack-core in my locally built milo, but it did not work as expected. I also tried to add a Groovy script in the pom.xml, which runs after the bundle-plugin and the shade-plugin and appends org.eclipse.milo.shaded.com.google.common in the Manifest's export section. This partially worked and my OSGi project did not complain about missing constraints anymore. However, it only added the shaded package superficially because I get NoClassDefFoundErrors at runtime. I am also pretty sure that having a Groovy script running in the pom.xml is not really the way to go here.
I also think that the lifecycle/phase is the issue, but it is probably not possible to change the order of execution of the bundle-plugins.

[kevinherron]

@m-meingast try #1709?

[m-meingast]

@m-meingast try #1709?

Hello Kevin,
thank you for providing a fix for this issue. I pulled it and added the org.eclipse.milo.shaded.com.google.common.collect package to the <Export-Package> section. With the changes as per my suggestion in #1709, it finally worked and org.eclipse.milo.shaded.com.google.common.collect is written into the MANIFEST.MF of stack-core.

[kevinherron]

@m-meingast this is merged. I still need to test and merge #1711 (unrelated to this) and then I'll get a release out soon after.

[m-meingast]

@kevinherron Thank you for your great work!