[ 
https://issues.apache.org/jira/browse/OAK-12093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18086404#comment-18086404
 ] 

Julian Reschke commented on OAK-12093:
--------------------------------------

Ok, I was clearly wrong in that we can't control versions of transient 
dependencies at compile time without putting in an override.

So this is good in many cases. What sticks out is that we now define versions 
of artefacts that actually aren't used by us directly. I don't think that is a 
good idea, because it adds noise to the parent pom, just because we want to 
avoid downloads.

There'll be bit rot as well - when a transient dependency is actually gone, or 
the cause of the transient inclusion is. For example, the parent pom now 
defines a version for com.google.errorprone, and that will go anyway when we 
remove Guava.

There are other things which are indeed useful; such as fixing scopes of 
artefacts that we do use; in particular downgrading dependencies to test scope, 
but we really should not do all of this at once, for all the reasons before 
(unrelated changes in one ticket, bisecting issues...).



> Improve build by rationalizing dependencies
> -------------------------------------------
>
>                 Key: OAK-12093
>                 URL: https://issues.apache.org/jira/browse/OAK-12093
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>            Reporter: Benjamin Habegger
>            Priority: Minor
>         Attachments: duplicate-artifacts.md, parse_conflicts.py
>
>
> Currently many dependencies are declared explicitly in several modules and 
> leads to pulling duplicate dependencies:
> The goal of this ticket is to rationalize and centralize as much as possible 
> dependencyManagement to avoid these multiple versions.
> Current output of joined script analyzing dependency duplicates gives 37 
> duplicate artifacts in the dependency tree : [^duplicate-artifacts.md]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to