Skip to content

Commit

Permalink
Add resolved publishing section
Browse files Browse the repository at this point in the history
  • Loading branch information
JakeWharton committed Mar 28, 2024
1 parent 37857db commit a30e26a
Showing 1 changed file with 31 additions and 0 deletions.
31 changes: 31 additions & 0 deletions _posts/2024-03-28-nonsensical-maven-is-still-a-gradle-problem.md
Original file line number Diff line number Diff line change
Expand Up @@ -152,6 +152,37 @@ A Maven project with an OkHttp 4.12 dependency will now fail like this:

Now a Maven consumer can temporarily resolve the conflict, and go and ask the library maintainer to correct this configuration.

### Ignoring the problem with Gradle

Since Gradle is going to resolve to the newest version of a dependency, your tests end up running with the newest version rather than the declared version. As such, you can tell Gradle to replace your declared version with the resolved version when publishing.

This behavior is not Gradle's default, so we must choose it when setting up publishing. The [Gradle docs](https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:resolved_dependencies) has an example:

```groovy
publishing {
publications {
mavenJava(MavenPublication) {
versionMapping {
usage('java-api') {
fromResolutionOf('runtimeClasspath')
}
usage('java-runtime') {
fromResolutionResult()
}
}
}
}
}
```

There's very little harm in doing this, and it will prevent the Maven issue completely. Nice!

The tradeoff is that it somewhat undermines the versions you declare. Keep in mind, though, even if you declare a dependency version and resolve to that same version, a downstream consumer may resolve a newer version or force an older version.

For me, I want the versions which I declare to be those which are resolved, at least local to my project. So this solution isn't going to work, but it might for your projects.

(Thanks to [Paul Merlin](https://mastodon.social/@eskatos/112174733070682832) for suggesting this solution which was added after initial publishing)

### Trying to fix with Gradle

I'm going to outright dismiss "just don't use Maven" as a potential fix. There are lots of reasons not to use Maven that one can explore elsewhere. Ultimately it remains in widespread use, and you can either be sympathetic to those users or not.
Expand Down

0 comments on commit a30e26a

Please sign in to comment.