[
https://issues.apache.org/jira/browse/JENA-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17467221#comment-17467221
]
Andy Seaborne edited comment on JENA-2234 at 12/31/21, 10:43 AM:
-----------------------------------------------------------------
The dependencyManagement section of the top level Jena POM sets the dependency
and version for commons-codec to (currently) 1.15
https://github.com/apache/jena/blob/main/pom.xml#L353
You can also see that Jena controls the inclusion of commons-codec from other
resources because it needs version 1.14 or later (currently1.15).
You seem to have encountered the way that [maven resolves multiple dependencies
of the same
artifact|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html].
It is not "later/newest"; it is "nearest" in the dependency tree, and random
if they at the same depth.
There are two ways to deal with this:
* Directly depend on the artifact at the version required in your application.
* Exclude the transitive dependency from systems with older copies.
Best is to do both -- see example in Jena's top-level POM.
common-compress has been very good at compatibility, as are all Apache Commons
artifacts. A newer version should work.
See JENA-1898. Jena needs version 1.14 or later.
It would be a source code change to downgrade.
was (Author: andy.seaborne):
The dependencyManagement section of the top level Jena POM sets the dependency
and version for commons-codec to (currently) 1.15
https://github.com/apache/jena/blob/main/pom.xml#L353
You can also see that Jena controls the inclusion of commons-codec from other
resources because it needs version 1.14 or later (currently1.15).
You seem to have encountered the way that [maven resolves multiple dependencies
of the same
artifact|https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html].
It is not "later/newest"; it is "nearest" in the dependency tree, and random
if they at the same depth.
There are two ways to deal with this:
* Directly depend on the artifact at the version required in your application.
* Exclude the transitive dependency from systems with older copies.
Best is to do both -- see example in Jena's top-level POM.
common-compress has been very good at compatibility, as are all Apache Commons
artifacts. A newer version should work.
See JENA-1898. jena needs version 1.14 or later.
> might need commons codec version to coexist with other libraries
> ----------------------------------------------------------------
>
> Key: JENA-2234
> URL: https://issues.apache.org/jira/browse/JENA-2234
> Project: Apache Jena
> Issue Type: Improvement
> Components: Build
> Affects Versions: Jena 4.3.2
> Reporter: David Beaudet
> Priority: Minor
>
> I'm experimenting with Jena and RDF4J in the same application. The RDF4J
> project seems to pull in an older version of commons codec which causes an
> exception in Jena when reading a model due to non-existence of a hashing
> function in commons codec prior to version 1.14. Would it make sense to
> specify a minimum version for commons-codec?
>
> The exception can be replicated without including RDF4J by adding the
> following to the application's pom.
> <dependency>
> <groupId>commons-codec</groupId>
> <artifactId>commons-codec</artifactId>
> <version>1.13</version>
> <scope>runtime</scope>
> </dependency>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
