v1.1.6 causes issue with dependency management and local maven

[fombico]

We have a gradle module :core that is published to maven local. Another module in the same project, :app pulls it from maven local as a dependency. When updating the dependency management plugin to 1.1.6, this stopped working.

A sample repo to illustrate the issue is at: https://github.com/fombico/spring-dependency-management-issue.

On a side note, if we update the org.springframework.boot plugin to version 3.3.2, it will also exhibit the same behavior even if the io.spring.dependency-management plugin is 1.1.5.

I am not sure if this is related to #389, so I created a separate issue for it.

[wilkinsona]

Thanks for the report. Unfortunately, this is a side-effect of switching to the withDependencies callback to apply Maven-style exclusions (#384). This results in com.example.foo:core:0.0.0 being resolved before the :core:publishToMavenLocal task has run. It isn't found, Gradle remembers this, and any subsequent attempt to resolve the dependency then fails.

You can work around the problem by disabling the plugin's support for Maven-style exclusions:

dependencyManagement {
    applyMavenExclusions = false
}

Depending on your dependencies, this may then require you to exclude some unwanted transitive dependencies that will no longer be excluded automatically.

@jvandort, do you have any other suggestions here please?

[jvandort]

Unlike Maven projects, Gradle projects should not use mavenLocal to share artifacts between each other. They should be using project dependencies.

:app should declare a api(project(":core")) dependency in its dependencies block instead of using the combination of api "com.example.foo:core:${project.version}" and compileJava.dependsOn(":core:publishToMavenLocal")

[wilkinsona]

That was quick! Thanks, @jvandort. I was just writing something similar in an edit to my comment above which I won't bother making now.

Given that Maven Local shouldn't be used in this way in a Gradle build, I'm going to close this one. If that structure is, for some reason, unavoidable, the workaround above to disable Maven-style exclusions will avoid the problem. I think potentially having to declare some additional exclusions is a fair price to pay for the unconventional build structure and is definitely preferable to reverting #384 which would re-introduce the deprecation warning and prevent Gradle 9 compatibility.

On a side note, if we update the org.springframework.boot plugin to version 3.3.2, it will also exhibit the same behavior even if the io.spring.dependency-management plugin is 1.1.5.

This is due to Gradle's conflict resolution. In 3.3.2, Boot's plugin depends on 1.1.6 of the dependency management. The conflict between that transitive dependency and the dependency in the build script on 1.1.5 is resolved by selecting the highest version, 1.1.6.

[fombico]

Thanks for the quick response, I was able to verify the workaround. I'll also reconsider our current use of mavenLocal