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

chore: bump DAGP to 1.28.0. #1086

Merged
merged 1 commit into from
Dec 27, 2023
Merged

chore: bump DAGP to 1.28.0. #1086

merged 1 commit into from
Dec 27, 2023

Conversation

autonomousapps
Copy link
Owner

No description provided.

Comment on lines +342 to +348
onUsedTransitiveDependencies {
exclude(
// TODO(tsr):
// 1. version catalog ref (libs.relocated.asm) is not working for some reason
// 2. This fatjar is bundling Kotlin stdlib classes, which is what the analysis is detecting
// 3. The exclusion only works when I use the project reference, not the Maven coordinates
":asm-relocated",
Copy link
Owner Author

@autonomousapps autonomousapps Dec 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jjohannes see point 3. This bug only appeared after I accepted your changes regarding how DAGP references internal projects (and I'm not blaming that change). Any idea why the exclude would work with :asm-relocated but not the full Maven coordinates?

nb, points 1 and 2 are things I will investigate.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not 100% sure without diving deep into the code again... but I think it is like this:

We have the bevior that a component can have two represenations if it is a local project. In this case:

  1. project(":asm-relocated")
  2. com.autonomousapps:asm-relocated

Both are tracked throughout the analysis. But at the end, a decisions is made which is the "primary" representation.
We decide that based on what was used when the dependency was declared if possible, that's why it should be right to use (2) here. We declare it like that in the Version Catalog.

Maybe here, we do not have the declaration tracked? (either on purpose, or it's a bug). In that case, I think we decide as follows: If we are inside the multi-project to which the corresponding project belongs, we decide for (1), otherwise for (2). In a single build, this is the case for every project. In a composite build, this is the case for any project in the root build.

Now if the "exclusion" runs late on the analysis results (which I think is the case) it only looks at this "primary" representation because that decision has been made.

@autonomousapps autonomousapps merged commit 576f735 into main Dec 27, 2023
@autonomousapps autonomousapps deleted the trobalik.dagp branch December 27, 2023 18:48
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

Successfully merging this pull request may close these issues.

2 participants