jakarta.mail fails to resolve due to required org.glassfish.hk2.osgiresourcelocator dependency

[paulsp]

Describe the bug org.eclipse.angus/jakarta.mail/2.0.1 has a required dependency on org.glassfish.hk2.osgiresourcelocator which according to several discussion, the dependency should be optional or removed as it is used by jakarta.mail/jakarta.mail-api/2.1.1

• https://github.com/jakartaee/mail-api/issues/629
• https://github.com/jakartaee/mail-api/blob/2.1.1-RELEASE/api/src/main/java/jakarta/mail/util/FactoryFinder.java lines 51 to 63

To Reproduce In a clean OSGi 8 environment, Install and start the following bundles:

• jakarta.activation/jakarta.activation-api/2.1.1
• jakarta.mail/jakarta.mail-api/2.1.1
• org.eclipse.angus/angus-activation/2.0.0
• org.eclipse.angus/jakarta-mail/2.0.1

Using Karaf, the feature scr is also required.

Expected behavior If osgiresourcelocator is used by angus-mail, then then the import dependency should be marked as optional. org.glassfish.hk2.osgiresourcelocator;resolution:=optional Otherwise the entry should be removed

Desktop (please complete the following information):

• OSGi 8, using the Apache Karaf 4.4.3

[mnlipp]

All this renaming makes things difficult and I'm not sure if I'm right, but...

I think you shouldn't use org.eclipse.angus/jakarta-mail/2.0.1. To be honest, I don't know what it is good for.

I have just successfully tested this combination:

• jakarta.activation/jakarta.activation-api/2.1.1
• org.eclipse.angus/angus-activation/2.0.0 (plus https://github.com/eclipse-ee4j/angus-activation/pull/37)
• jakarta.mail/jakarta.mail-api/2.1.1
• org.eclipse.angus/angus-mail/2.0.1 (plus https://github.com/eclipse-ee4j/angus-mail/pull/88)

So I had the latest specification (jakarta) bundles and the work-in-progress implementation (angus) bundles. Worked and didn't require org.glassfish.hk2.osgiresourcelocator any more.

[lukasj]

org.eclipse.angus/jakarta-mail/${angus-mail.version} is there for the case one prefers to have less jars on the cp/mp, less dependencies and/or those who prefer having an API with some default (ie for the provider availability in tests without the need for adding additional runtime/test dependencies)