IssueTracker

Jeff, can we set up atomically-versioned groups to treat within-group project(...) dependency versions as strictly(version)?

It seems to me that the code in comment #1 is detecting the “[“ and “]” in the .pom files and using it to determine which dependencies are supposed to be strict, and that if we were to stop including the brackets in newly published .pom files then the dependencies in those newly published artifacts would be interpreted as non-strict with potentially no warning in case of a conflict.

Nowadays AndroidX is publishing Gradle module metadata; it might be more convenient for dependents to use that, which should be automatic if the corresponding AndroidX artifact was published with a .module file (for example, https://dl.google.com/dl/android/maven2/androidx/room/room-runtime/2.3.0-alpha01/room-runtime-2.3.0-alpha01.module ) and the application is using a new enough version of Gradle.

Also related is it appears that the module metadata that we’re publishing doesn’t currently specify ‘strictly’ in this case, but I’ll look into that.

Hmm, asked Gradle whether there was a convenient way to add these version constraints into the .module file when they are coming from project dependencies in our build, and they suggested filing a feature request: https://github.com/gradle/gradle/issues/15706

Does comment#15 mean that the pom version specification is always considered by Gradle to be require? Such that the suggestion in comment#12 to use strictly isn't something that can be expressed in a pom. It wasn't entirely clear to me from the Gradle bug.

From the docs it sounds like strictly and prefer in a pom (or Gradle metadata) would also allow us to specify SemVer constraints. I could have sworn that was already supposed to be possible in Gradle metadata.

Re comment #17

Yeah, according to https://github.com/gradle/gradle/issues/8297 , Gradle was planning to interpret "[16.0.6]" in a .pom as strict version but then decided against it and currently interprets it as require, yeah.

Re comment #18

Yeah, it is possible for a gradle module metadata file to specify a dependency version of strictly but it's inconvenient to generate a file like that in our case where the original build dependencies are project dependencies (comment #16)

Using a BoM can solve your problem I think. Otherwise, you can submit the feature request to have it be supported easily for project dependencies.

This would have helped developers avoid a crash in a mix of alpha and beta versions of emoji2: b/200172522

This would have addressed b/253443289 for Lifecycle, as well. Raising the priority since we're duping P1 issues every few months and building up code debt to work around this manually.

Checking again on the gradle issue from Comment #16 (requesting the ability for projects to publish strictly() constraints into .module files),

one of the ideas is reciprocal version constraints, (where I think A:1.0 requires at least B:1.0 (if B is present) and B:1.1 requires at A:1.1 (if A is present)).

Does that appear to apply here? Should we ask Gradle again about whether there's an update?

Whoops, we should have resolved that way earlier. No -- we don't want strictly. This should always be reciprocal requires constraints so that we upgrade instead of fail.

Oh, and a fun hack we learned along the way! Aurimas had expressed concerns about project isolation.

If you express a constraint as though it's a prebuilt, e.g. implementation("myGroup:myLibraryA:${LibraryGroups.MY_GROUP.version}"), then you won't have a configuration- or build-time dependency on the project; however, the constraint will still get emitted into the Gradle metadata. There's no need for an actual prebuilt to exist, since Gradle doesn't exercise the constraints until they are needed during dependency resolution. When they are exercised, Gradle will correctly resolve the constraint to the project.

Within the next couple of releases we should start seeing reciprocal constraints being published into .module files for projects in atomically-versioned groups in AndroidX