Missing OSGI package-exports from core-module
stoerr opened this issue · comments
Hi!
Thank you for providing OSGI-headers in simple-java-mail to make it deployable as bundle! Unfortunately I get some trouble when trying to deploy it, together with it's required OSGI-bundles (core-module, jakarta.mail, jakarta.activation, emailaddress-rfc2822, jetbrains-runtime-annotations). I get some errors in the OSGI console (specifically, I'm using Felix in Apache Sling ):
org.simplejavamail.api.internal.authenticatedsockssupport.socks5server -- Cannot be resolved
org.simplejavamail.api.internal.batchsupport -- Cannot be resolved
org.simplejavamail.api.internal.clisupport.model -- Cannot be resolved
org.simplejavamail.api.internal.outlooksupport.model -- Cannot be resolved
org.simplejavamail.api.internal.smimesupport.builder -- Cannot be resolved
org.simplejavamail.api.internal.smimesupport.model -- Cannot be resolved
org.simplejavamail.internal.util -- Cannot be resolved
It seems all these packages are contained in the core-module, which was successfully deployed and active. But it does not export those: it's exported packages are
org.simplejavamail,version=6.4.3
org.simplejavamail.api.email,version=6.4.3
org.simplejavamail.api.mailer,version=6.4.3
org.simplejavamail.api.mailer.config,version=6.4.3
org.simplejavamail.config,version=6.4.3
Could you please fix this? Thank you very much!
Best regards,
Hans-Peter Störr
To be honest I know next to nothing about OSGI and the only reason the headers you mention are there is because of pull request #146. So if you know how to fix this, by all means, open a pull request.
Hi,
I stumbled upon the same problem, while trying to use simple-java-mail within an Apache Karaf Runtime Environment. Exports for internal packages are missing. I guess they're not exported autoamtically, because of the ".internal." part in the package names. It's best practice to not export internal packages and the maven-bundle-plugin perhaps follow this practice if running with defaults.
The whole problem results from class loader isolation in OSGi. Every "bundle" (a deployable .jar with bundle information added to its MANIFEST.MF) resides in its own class loader and lookups to other bundles are controlled by package export/import declarations and dynamic dependency injection. Splitting a project in multiple modules whereas not providing these declaration makes it nearly impossible to use this project without restructuring the project.
Therefore I created a simple test project simple-java-mail-osgi.zip to re-bundle all needed simple-java-mail modules into one osgi bundle with complete package export/import declarations. There are just some extra instructions for the maven-bundle-plugin needed to achieve this.
While inspecting the resulting artifact, I recognized an auto generated import declaration org.jacoco.agent.rt.internal_c13123e alongside some other requirements and thought they came from some "auto import" magic and prohibited their creation by adding it to the maven-bundle-plugin instructions with a leading ! in front of it.
The bundle deployed and resolved straightforward and I start trying to use it. But when trying to compose an email via
EmailPopulatingBuilder emailBuilder = EmailBuilder.startingBlank();
the runtime crashes resulting in a
java.lang.NoClassDefFoundError: org/jacoco/agent/rt/internal_c13123e/Offline (Stacktrace attached)
Why is simple-java-mail relying on the jacoco offline agent during runtime? Is this a result of the jacoco instrument usage?
I hope someone could check my attached solution and acknowledges the results. Thanks!
Kind regards,
Rene Greuel
Stacktrace: stacktrace.txt
It doesn't rely on it in runtime, not sure why you get that result (did you locally build Simple Java Mail and do an mvn install with that?). For actual deploys jacoco is skipped altogether, there really should be no trace of Jacoco once distributed. This is the deploy command used in the CircleCI pipeline, on a clean filesystem (so no old build results tainting the release, aside from the mvn clean being run):
mvn -s .circleci/maven-release-settings.xml clean deploy -DdeployAtEnd=true -DperformRelease=true -DskipTests -Dspotbugs.skip=true -Denforcer.skip=true -Djacoco.skip=true
The project packages fine for me but I have no idea how to test this and to reproduce your problem. Perhaps you can have another look with a later version (I just released 6.7.5)? That would be much appreciated