[
https://issues.apache.org/jira/browse/TIKA-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686061#comment-16686061
]
Hans Brende commented on TIKA-2778:
-----------------------------------
[~talli...@apache.org]
+1, I think manually excluding javax.activation-api everywhere it occurs is the
only way to go here. Since javax.activation-api itself has a compile-time
dependency on the classes in com.sun.activation, using it in any capacity, as
far as I can see, is prone to disaster.
I have no freaking clue why anyone would design an api module in this manner.
> Upgrade jaxb-runtime and javax.activation
> -----------------------------------------
>
> Key: TIKA-2778
> URL: https://issues.apache.org/jira/browse/TIKA-2778
> Project: Tika
> Issue Type: Task
> Components: parser
> Affects Versions: 1.19.1
> Reporter: Hans Brende
> Priority: Major
>
> The latest version of org.glassfish.jaxb:jaxb-runtime is 2.3.1, which fixes a
> few issues on Java 11. A few important notes to take into consideration:
> 1. jaxb-core is no longer a separate artifact, but has been merged into
> jaxb-runtime.
> 2. jaxb-runtime now pulls in the latest version of the activation API, which
> is: javax.activation:javax.activation-api:1.2.0. *However*, this artifact
> does not include a couple of the source files found in
> javax.activation:activation:1.1.1 (namely, those found in the
> com.sun.activation.* packages). The activation artifact which includes those
> extra sources has moved to: com.sun.activation:javax.activation:1.2.0.
> *However*, if I'm seeing this correctly, the com.sun.activation artifact
> *duplicates* all the code found in the activation-api artifact, rather than
> depending on it. If that's the case, and *if* you still need those extra
> classes in the activation artifact, one might need to manually exclude the
> activation-api artifact pulled in by jaxb-runtime. But, I'm not 100% certain
> here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
