Created attachment 273510 [details] Change RUN_DEPENDS javax-activation-api is mostly deprecated, jakarta-activation-api is preferred. Note: when jakarta.activation-api is used, jakarta.activation.jar, installed by java/javamail, is often needed too.
Thank you for the patch, Thierry. As maintainer I can't apply it as-is — it would break devel/jaxb-api at runtime. devel/jaxb-api is jakarta.xml.bind-api 2.3.3. Despite the "jakarta" groupId, the 2.3.x line still lives in the javax.activation namespace, not jakarta.activation — that migration only happens in jaxb-api 3.x/4.x. Evidence from the 2.3.3 jar itself: META-INF/MANIFEST.MF → Import-Package: javax.activation, ... javax.xml.bind.attachment.AttachmentMarshaller / AttachmentUnmarshaller reference javax.activation.DataHandler (methods addMtomAttachment, addSwaRefAttachment). There are no jakarta.activation references. devel/jakarta-activation-api provides jakarta.activation.*, so it does not satisfy jaxb-api's javax.activation requirement. Switching RUN_DEPENDS accordingly produces a runtime failure. Reproducer (OpenJDK 17, which does not bundle javax.activation, so only the classpath counts): A) cp = jaxb-api-2.3.3 + jakarta.activation-api-2.1.4 (this patch) -> java.lang.NoClassDefFoundError: javax/activation/DataHandler B) cp = jaxb-api-2.3.3 + jakarta.activation-api-1.2.2 (upstream filename; the port installs this as javax.activation-api.jar -> devel/javax-activation-api) -> OK: addMtomAttachment(javax.activation.DataHandler, ...), addSwaRefAttachment(javax.activation.DataHandler) Note this is not caught by a poudriere testport run: RUN_DEPENDS only requires the package to be present, so the build stays green and the breakage only surfaces at runtime on the classpath. Relevant context: I need devel/jaxb-api to keep depending on devel/javax-activation-api for my ongoing freeipa-server porting work. In that chain security/dogtag-pki (FreeIPA's CA/PKI component) has jaxb-api as a runtime dependency and itself uses javax.activation, so this swap would break the FreeIPA port stack. The correct path to jakarta would be to update devel/jaxb-api itself to the 3.x/4.x (jakarta.xml.bind-api) line — a separate, larger change with consumer fallout (all javax.xml.bind users), which I'd be glad to coordinate on. I'm leaving this bug open rather than closing it: if I've missed something or you see open points, I'd genuinely like to hear your feedback first — closing it out from under the discussion would feel impolite. Happy to keep talking it through.
OK, I see, thanks for the reply. I opened this PR because I encountered a runtime problem in one application, due to difficulties of javax-activation-api getting along with jakarta-activation-api. Thedrefore I'll try to see how it goes with jaxb-api 3.x/4.x.
Thanks, that makes sense — and your runtime problem is real: mixing javax.activation and jakarta.activation on one classpath does clash (split/duplicate DataHandler etc.). The right fix is exactly what you're doing: move the consuming application to the jakarta stack (jaxb-api 3.x/4.x + jakarta-activation-api), rather than swapping the activation dep under jaxb-api 2.3.3, which still needs the javax namespace. If it helps: a jaxb-api 3.x/4.x port would be co-installable with the current one (different jar, jakarta.xml.bind-api.jar), so it can land without disturbing the existing javax-namespace consumers (e.g. security/dogtag-pki, which I depend on for the freeipa-server work). Happy to help review/test such a port if you decide to go that route — just CC me. I'll leave this open for now in case you want to fold it into that jaxb-api 3.x/4.x effort; feel free to repurpose or close it as you see fit.
Closing: I've found a solution with the ancient activation.jar! Sorry for the noise.