CODEWITHSUNDEEP
javamavengradle
meistermeier
meistermeier

Reputation: 8262

Maven BOM dependencies in Gradle

Given that there is a BOM listed in the dependency management of a Maven project Foo like this:

<groupId>someGroup</groupId>
<artifactId>someArtifact-bom</artifactId>
<version>1.0-SNAPSHOT</version>
<type>pom</type>
<scope>import</scope>

but this BOM comes only into play for a test dependency in a sub-module.

<dependency>
    <groupId>someGroup</groupId>
    <artifactId>someArtifact</artifactId>
    <scope>test</scope>
</dependency>

The artifact declared in the BOM and BOM itself are only available by declaring an additional repository.

If I create a new Maven project and declare the dependency to Foo it gets resolved.

In case I define the very same dependency to Foo in a Groovy project

repositories {
  mavenCentral()
}

dependencies {
  implementation("myOrg:Foo:1.0")
}

The resolve fails with

- Could not resolve myOrg:Foo-parent:1.0.
  - Could not parse POM <mvn-central>/myOrg/Foo-parent-1.0.pom:
    - Could not find someGroup:someArtifact-bom:1.0-SNAPSHOT.

...because it does not exist on central.

Of course it can get easily solved by adding the repository, if accessible from the user's project, or putting the BOM and its declared artifacts on central.

I wonder if there are another approach that I couldn't come up with to avoid this problem in the future. An exclude on the dependency definition does not work for BOMs. I can understand this behaviour because a BOM is not a real module.

Just for completeness: After a correct resolve there is no dependency regarding the BOM or its artifact in my project. It is really not needed at all.

Upvotes: 4

Views: 3833

Answers (2)

Louis Jacomet
Louis Jacomet

Reputation: 14500

To be complete, what you experienced with Gradle looks like the expected behaviour to me.

Gradle will not dynamically add repositories defined by dependencies. This is because it can become a security risk where an added repository could attempt to shadow popular packages with poisoned artifacts. So the right solution in Gradle is to add the extra repository when required.

With a number of changes that went into how Gradle interprets BOMs and loads Maven POM files, it could very well be that since the BOM is not required, more recent Gradle version will happily ignore it.

But the root problem, transitively adding random repositories, will not be done by any Gradle version.

Upvotes: 4

meistermeier
meistermeier

Reputation: 8262

Thanks to the comment of Corneil du Plessis I took a deeper look in trying out different Gradle versions and a newer one fixed the problem. Going back later to the original version that made me aware of the problem (5.2.1) it kept resolving the dependency without any error.

To be really sure I cleared the local Gradle caches and re-ran the build with success.

Since I cannot reproduce the issue anymore with either 5.x nor 6.x I am pretty sure that this was related to the cache and the history of Gradle on my machine.

I think it makes sense to answer my question by myself instead of just closing it to leave the information here.

Upvotes: 1

Related Questions