IssueTracker

@alanv - can you share an example of this where it broke?

I'm not sure if anything has broken, but we didn't design any of the tooling to accommodate this use case. We could either prevent it or deliberately support it by auditing all of the group-related code in our tooling.

Don't we support it multiple atomic groups using the same maven group id? For example, the maven group androidx.camera has multiple atomic groups in libraryversions.toml

CAMERA = { group = "androidx.camera", atomicGroupVersion = "versions.CAMERA" }
CAMERA_PIPE = { group = "androidx.camera", atomicGroupVersion = "versions.CAMERA_PIPE", overrideInclude = [ ":camera:camera-camera2-pipe", ":camera:camera-camera2-pipe-integration" ] }
CAMERA_TESTING = { group = "androidx.camera", atomicGroupVersion = "versions.CAMERA_TESTING", overrideInclude = [ ":camera:camera-testing" ] }

We shouldn't have allowed that -- it looks like the same workaround for quarantined libraries that Ian was using, e.g. a temporary 1.0.0-alphaXX within an atomic group until the library catches up.

Project: platform/frameworks/support
Branch: androidx-main
Author: Omar Ismail <omarismail@google.com>
Link:      https://android-review.googlesource.com/3528590

Check for duplicate atomic group IDs

Check for duplicate atomic group IDs 
 
This change adds a check to ensure that multiple atomic groups are not defined with the same Maven group ID. If duplicate atomic group IDs are found, a GradleException will be thrown. 
 
BUG: 399124813 
TESTED: Ran `./gradlew tasks` 
Change-Id: I19dd63dad54ea3c9c48f8c583590e7ce1e843dbe