You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Andy Seaborne (Jira)" <ji...@apache.org> on 2020/05/17 17:42:00 UTC
[jira] [Resolved] (JENA-1898) Force commons-code dependency to be
Jena parent POM choice
[ https://issues.apache.org/jira/browse/JENA-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Seaborne resolved JENA-1898.
---------------------------------
Resolution: Fixed
> Force commons-code dependency to be Jena parent POM choice
> ----------------------------------------------------------
>
> Key: JENA-1898
> URL: https://issues.apache.org/jira/browse/JENA-1898
> Project: Apache Jena
> Issue Type: Task
> Affects Versions: Jena 3.15.0
> Reporter: Andy Seaborne
> Assignee: Andy Seaborne
> Priority: Minor
> Fix For: Jena 3.16.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I have a project where the dependency resolution causes the commons-code from Apache httpcomponents to be chosen (v1.11), not the version needed by Jena (v1.14).
> Maven dependency rules: [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]
> The project depends on several Jena artifacts and the encounter order of dependencies can matter.
> This happens with maven 3.6.3, which is current latest.
> Clearing up the projects dependencies will also fix the problem but leaves it to the user to deal with it. (The project is an old and messy scratch working area and the POM isn't neat and tidy. It was bringing in Jena test code.)
> To be safe, this ticket is to force the dependency resolution by excluding common-codec from the org.apache.httpcomponents (httpclient and httpclient).
> Then at least the order of any Jena artifacts does not impact the outcome.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)