[
https://issues.apache.org/jira/browse/JENA-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17109443#comment-17109443
]
ASF subversion and git services commented on JENA-1898:
-------------------------------------------------------
Commit 3eda69359bce3fafddeb79ccfa77d865d2c2d823 in jena's branch
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=3eda693 ]
Merge pull request #746 from afs/jena1898_commons-code
JENA-1898: Exclude commons-codec from httpcomponents dependencies
> 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)
