[
https://issues.apache.org/jira/browse/JENA-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17229235#comment-17229235
]
ASF subversion and git services commented on JENA-1898:
-------------------------------------------------------
Commit da2e8ddc3c833a94687d2b2ec2cbe1909151f36f in jena's branch
refs/heads/master from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=da2e8dd ]
JENA-1898: Log output for webapp
> Force commons-codec 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-codec
> 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)
