Transitive dependency resolution non-repeatable with version ranges about gradle

[eriwen]

@rocketraman I'm sorry, I wish I could, but I'm legally not allowed to under the particular open-source partnership this is a part of. Will let you know once we can announce it.

[oehme]

@eriwen I wouldn't classify this as a bug. Repeatable builds in the face of version ranges is a missing feature, which could e.g. be solved with a lock file or something similar.

@rocketraman For the time being, you can force the version of the transitive dependency to a stable one. You can also write some code which makes your build fail if any dynamic or changing dependencies are used. See the ResolutionStrategy documentation for further details.

[rocketraman]

For the time being, you can force the version of the transitive dependency to a stable one.

Agreed, this is an ok solution until builds can be repeatable by handling this situation in gradle.

You can also write some code which makes your build fail if any dynamic or changing dependencies are used. See the ResolutionStrategy documentation for further details.

This would be useful, so that the build can fail-fast when one needs to apply the workaround above. I know this is not a support forum, but can you provide an example of this? The documentation does not have one.

[oehme]

You can use ResolutionStrategy.eachDependency() and inspect the version of the requested module. If it contains things like ( or + or -SNAPSHOT, you fail the build. Hope that helps :)

[eriwen]

Thanks @oehme. We are aware of the need to make transitive dependencies deterministic, and I'd like to track that somewhere else than this issue.

Given that there's a workaround here, I will close this. Please reopen @rocketraman if you desire further discussion.

[rocketraman]

For future reference, can you provide a link to whichever issue was created to track deterministic dependencies?

[rocketraman]

For future reference, can you provide a link to whichever issue was created to track deterministic dependencies?

@eriwen Ping

[samrocketman]

^^ that seems lame and opaque. I've not heard of such a partnership which claims to be "open source" and legally forbids transparency of viewing issues. Seems kind of mental to me.

Also, FWIW I'm having HUGE repeatability issues with gradle and it makes me wonder if I still want to use it. Oh, and you can verify my claim since I'm more willing to be open.

git clone https://github.com/samrocketman/jervis
cd jervis
./gradlew clean Jar
sha256sum build/libs/* > /tmp/sha256sums
./gradlew clean Jar
sha256sum -c /tmp/sha256sums

I'm still trying to figure out why my build isn't repeatable without any code changes.

[oehme]

^^ that seems lame and opaque.

I agree that this comment was vague. In fact there is no such partnership, the comment was intended for a different issue.

I've not heard of such a partnership which claims to be "open source" and legally forbids transparency of viewing issues. Seems kind of mental to me.

There are partners who pay us for improving Gradle for everyone, but don't want to be named or don't want us to make a big fuss about it before it is ready. These partnerships are improving the tool that you are using for free. So your comment of such a partnership being "mental" is odd, to say the least.

I'd appreciate if you'd drop the needlessly rude and hurtful language in the future.

I'm still trying to figure out why my build isn't repeatable without any code changes.

GroovyDoc puts timestamps into its output by default. You can disable that.

[samrocketman]

@oehme thanks for the tip on timestamps, I didn't mean to come off as rude. I was only making an observation. Your statement can apply to pretty much all popular freely licensed and open sourced software. I still think it's unwise to keep an issue relating to a desired open source feature in a closed and opaque issue tracker. It makes me not want to contribute if that's how this project operates in general (i.e. all open issues are closed in favor of a "private" issue tracker). I encourage you as maintainers to develop and track issues more in the open.

[oehme]

We didn't close this issue in favor of some internal one. We closed it because it was not a bug and because there was a workaround for the issue described. There is no ticket for the broader topic of "repeatable dynamic versions" yet, but you are very welcome to open one. We did not open one ourselves because we don't have the capacity to work on it or discuss it at this point.

That being said, there is a great community plugin for dependency locking (which is one way to solve "repeatable dynamic versions").

[rocketraman]

We didn't close this issue in favor of some internal one. We closed it because it was not a bug and because there was a workaround for the issue described.

@oehme As far as I know, no one was asking why this issue was closed. That was clear. @eriwen stated:

I'd like to track that somewhere else than this issue.

So would we. This is what we were asking for. Now that its clear this place does not currently exist, we can move forward :-)

Thanks for the link to the community plugin also.

[rocketraman]

FYI - I think this is a relevant issue for the community plugin:

nebula-plugins/gradle-dependency-lock-plugin#78

[rocketraman]

And for future Google searchers, this was eventually implemented in Gradle core: https://docs.gradle.org/current/userguide/dependency_locking.html.