Feature request: filter out BOM artifacts

[ZacSweers]

These are not actually a real dependency, rather they just dictate the version of other dependencies owned by it. This leaks across buildscript classpaths too. For example - buildscript { dependencies { classpath(platform(libs.coroutines.bom)) } } will make this show up as a configuration dependency in all subprojects using dependencyGuard as well even if they don't use coroutines. My sense here is that it should filter these.

[handstandsam]

Nice, I don't have any projects using a bom. Can you provide an example GAV for one and I can work on an example based on that.

[ZacSweers]

Kotlin has one - org.jetbrains.kotlin:kotlin-bom

[handstandsam]

I'm hoping to get to this one soon. There is a large configuration cache PR I'd want to get in first (as it changes a bunch), but this should be fun one to learn about boms for me. :-)

Thanks for your patience.

[handstandsam]

Finally hitting this issue now that we're bringing in the compose-bom. From a technical standpoint, I'm not sure how to approach it quite yet.

This is our code used to traverse the dependency tree and collect info about artifacts.

dependency-guard/dependency-guard/src/main/kotlin/com/dropbox/gradle/plugins/dependencyguard/internal/DependencyVisitor.kt

Lines 18 to 24 in 10ee510

	is ModuleComponentIdentifier -> {
	ArtifactDependency(
	group = componentIdentifier.group,
	artifact = componentIdentifier.module,
	version = componentIdentifier.version,
	)
	}

ModuleComponentIdentifier (source link) doesn't tell me the packaging type of the artifact which is what I'd use to distinguish aar/jar/bom/etc.

Are you aware of another Gradle API to traverse the dependency tree which contains packaging info? That would allow this change to be made.

Again, thanks for your patience on this issue!

[handstandsam]

A workaround could be to add

baselineMap = { 
  if (it.contains("-bom") {
    null 
  } else {
    it
  } 
}

Returning null from the baselineMap lambda will remove it from the baseline file.

Gross, but a possible workaround.

[handstandsam]

@ZacSweers - @devPalacio and I have been adding Version Catalogs on our projects here and see the same behavior. Because these show up in the ./gradlew :module:dependencies list, this seems like it is the "correct" behavior.

Please use the baselineMap suggestion above as a way to filter out those bom entries from the baseline files if you do not want them in your baselines.

---

I'm going to close this since:

• There is no way (with the current APIs we use, or that I know of) to detect the artifactType of a dependency when we traverse them. So, there is no way to determine which ones are BOMs.
• Current behavior reflects how Gradle resolves dependencies as well.
• We've provided a way for you to achieve your desired output.

Thank you, and we can re-open if you are aware of some way we can do this which is cleaner.

[ZacSweers]

It appears that it is possible to determine this. This is how licensee did it: cashapp/licensee#311

[handstandsam]

If this is added, do we have it behind a flag, or make it default behavior?

[ZacSweers]

Make it the default for sure

[mezpahlan]

Hey all 👋 Can I just check if this is the same as an issue I am seeing, please.

When I run ./gradlew depedencyGuard on our CI I get no failure:

Linux 5.10.220-209.869.amzn2.x86_64 (amd64)
Eclipse Temurin OpenJDK Runtime Environment 17.0.12+7
Gradle 8.7
Gradle Enterprise plugin 3.15.1
Android Gradle plugin 8.5.2
Dependency Guard 0.5.0

When I run the same command on the same commit locally it fails:

Linux 6.8.0-45-generic (amd64)
JetBrains s.r.o. OpenJDK Runtime Environment 21.0.4+-12422083-b607.1
Gradle 8.7
Gradle Enterprise plugin 3.15.1
Android Gradle plugin 8.5.2
Dependency Guard 0.5.0

The difference seems to be from a single dependency which not present locally but seems to appear only on the CI.

Dependencies Changed in :app for configuration appUkReleaseRuntimeClasspath
- org.jetbrains.kotlinx:kotlinx-serialization-bom:1.6.3

If I follow the rebaseling instructions locally and push to the CI I get the reverse error (the dependency was found but not declared).

Have I stumbled upon this issue or is my issue different? I'm happy to raise a new issue if so. ❤️

[azabost]

@mezpahlan I think your issue could be the same or similar to: #43

Not sure if it's related to this one though.

By the way, I have been affected by a similar problem (different results locally and on CI) in one of the projects in the past.

[mezpahlan]

Thanks @azabost I'll monitor that issue.