Hi David,
You could try to add the Jackson BOM in the parent dependencyManagement.
That would override all versions in the (transitive) dependencies of the
child modules. For a nice explanation of BOM files, see Baeldungs blog post
[1].
<project ...>
<modelVersion>4.0.0</modelVersion>
<groupId>baeldung</groupId>
<artifactId>Test</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<name>Test</name>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.fasterxml.jackson</groupId>
<artifactId>jackson-bom</artifactId>
<version>2.13.5</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>
[1] https://www.baeldung.com/spring-maven-bom
Nick Stolwijk
~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~
Lord Baden-Powell
On Sat, 29 Jul 2023 at 01:29, David Karr <davidmichaelk...@gmail.com> wrote:
> In general, I know how to override transient artifact versions. You add an
> "exclusion" for the artifact on the dependency that is including that
> dependency, and then you manually add that dependency in the same pom where
> you added the exclusion. In my case, the version I want is defined in a
> bom in our parent pom, so I don't have to specify the version in that
> dependency.
>
> This works fine, if I do this exclusion and inclusion in the overall "child
> pom".
>
> However, I maintain the parent pom and platform, and there will be dozens
> of "child poms" that will need to do this. I would much rather do this
> "fixup" in the poms for the libraries in our platform. Those poms specify
> the dependencies whose versions I need to control.
>
> I've been struggling with trying to do this, along with trying to
> understand the output of "mvn dependency:tree" and the apparently
> functionally similar output in the "Dependency Hierarchy" view in Eclipse
> using the m2e plugin. Although I can loosely see the hierarchical output
> from these, I find determining the actual details of where dependencies are
> coming from is very mystifying.
>
> To get down to actual details, my problem is that I'm ending up with
> different versions of "jackson-core" and "jackson-databind". I need to
> ensure that I have the same versions of both. I am getting v2.14.1 of
> jackson-databind and v2.13.5 of jackson-core. We are specifying v2.13.5 in
> our parent pom, but somehow something in the tree is giving us v2.14.1 of
> jackson-databind.
>
> I'm going to include here a small excerpt of the "dependency:tree" output
> for our child pom:
>
> com.att.idp:RiskAssessmentMS:jar:2.8.0
> +- com.att.idp:idp-seed-sdk-core:jar:2.8.0:compile
> +- org.jasypt:jasypt:jar:1.9.3:compile
> +- com.io7m.xom:xom:jar:1.2.10:compile
> +- com.att.idp:idp-health:jar:2.8.0:compile
> | +- org.springframework.boot:spring-boot-actuator:jar:2.7.5:compile
> | +- com.att.idp:idp-logging-core:jar:2.8.0:compile (version selected from
> constraint [2.8.0,2.8.100))
> | | \- ch.qos.logback:logback-core:jar:1.2.9:compile
> | +- redis.clients:jedis:jar:3.8.0:compile
> | | \- org.apache.commons:commons-pool2:jar:2.11.1:compile
> | +- com.github.fppt:jedis-mock:jar:0.1.23:compile
> | | \- com.google.auto.value:auto-value-annotations:jar:1.6.2:compile
> | \- com.att.idp.voltage:vibesimplejava:jar:6.21.0.0:compile
> +- com.fasterxml.jackson.core:jackson-core:jar:2.13.4:compile
> +- com.fasterxml.jackson.core:jackson-databind:jar:2.14.1:compile
>
> The "idp-health" library is one of our wrapper libraries. That specifies
> dependencies that pull in jackson-databind, and in those dependencies I
> have excluded jackson-databind and included a specific dependency for
> jackson-databind. As the bom imported from the parent pom specifies v2.13.5
> for that, I would expect I would get jackson-databind v2.13.5, but I'm
> still getting v2.14.1.
>
> I'm very confused.
>
> I think I remember seeing discussions in the dev list about improving the
> output of dependency:tree to be clearer, I don't know if there's been any
> progress on that.
>
