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

Also exclude omitted dependencies #4563

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

ckcd
Copy link
Contributor

@ckcd ckcd commented Oct 9, 2024

The root cause should be when parse resolved pom, we ignore the omitted dependencies so that these information is lost.

So I try to add a new omitDependencies list for ResolvedDependency to record these omitted information. And uses this omitDependencies when search for potential relation in ExcludeDependency. To avoid affecting other logic, I added a new method findDependencyWithOmit.

What's changed?

ExcludeDependency also exclude omitted dependencies.

What's your motivation?

When conflicts occur dependencies are omitted; when we then exclude from the conflict, the omitted dependency can resurface. The goal of ExcludeDependency is to fully exclude a dependency, not to see the omitted conflict being used. We should then also add <exclusion> where dependencies are omitted.

Anything in particular you'd like reviewers to focus on?

Anyone you would like to review specifically?

Have you considered any alternatives or workarounds?

Any additional context

Checklist

  • I've added unit tests to cover both positive and negative cases
  • I've read and applied the recipe conventions and best practices
  • I've used the IntelliJ IDEA auto-formatter on affected files

Signed-off-by: Kun Chang <curtis@mail.ustc.edu.cn>
@timtebeek timtebeek added the bug Something isn't working label Oct 9, 2024
@timtebeek timtebeek mentioned this pull request Oct 27, 2024
3 tasks
@timtebeek
Copy link
Contributor

Thanks for the work here @ckcd ! Great to see you've found a way around the problem of omitted dependencies. The only thing giving me pause here is that we try to limit change to the ..tree.* classes, as those are serialized and thus require some more consideration before changing things there in a backwards compatible manner. Let us think over the options here a bit before committing to a particular solution. Much like Boolean optional I'm considering an Boolean omitted as one of the possible solutions, and then alter findDependency to exclude omitted dependencies by default. But perhaps there's more options still.

@ckcd
Copy link
Contributor Author

ckcd commented Oct 29, 2024

@timtebeek Thanks for your reply!

Sure for the boolean related I can refine the logic to make it more concise.

And just confirm, do you mean we can't add new field to ResolvedDependency? Generally add a field does not affect backward compatibility I think.

@timtebeek
Copy link
Contributor

Sure for the boolean related I can refine the logic to make it more concise.

Thanks! I think that's preferred over adding a collection field to ResolvedDependency that's only used for the very narrow use case of exclusions.

And just confirm, do you mean we can't add new field to ResolvedDependency? Generally add a field does not affect backward compatibility I think.

Some addition is possible, but indeed backwards compatible and ideally with minimal surface API changes if we can. That way there's less to review and maintain going forward.

@ckcd
Copy link
Contributor Author

ckcd commented Nov 5, 2024

Add @SiBorea

@SiBorea
Copy link

SiBorea commented Nov 5, 2024

@timtebeek I suggest we create new classes that extend ResolvedDependency and ResolvedPom, then create a new recipe ExcludeAllDepedency using them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Ready to Review
Development

Successfully merging this pull request may close these issues.

3 participants