Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: filter out BOM artifacts #54

Open
ZacSweers opened this issue Sep 19, 2022 · 9 comments
Open

Feature request: filter out BOM artifacts #54

ZacSweers opened this issue Sep 19, 2022 · 9 comments
Milestone

Comments

@ZacSweers
Copy link
Contributor

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 handstandsam added this to the 0.4.0 milestone Sep 23, 2022
@handstandsam
Copy link
Collaborator

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
Copy link
Contributor Author

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

@handstandsam
Copy link
Collaborator

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
Copy link
Collaborator

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.

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
Copy link
Collaborator

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
Copy link
Collaborator

@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
Copy link
Contributor Author

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

@handstandsam handstandsam reopened this Mar 28, 2024
@handstandsam
Copy link
Collaborator

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

@ZacSweers
Copy link
Contributor Author

Make it the default for sure

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants