[MSHADE-148] Don't attach exclusions that are already present #16
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Although I don't fully understand the scenarios where we re-evaluate the exclusions of a dependency, I do know that if we do, we will add them again, leading to a false indication that the dependency list has changed, leading to a regeneration and re-evaluation of the list, which then continues indefinitely, as the the same exclusions are added again and again. To address the leaf problem, let's ensure that we never add an exclusion that is already present. That way, even if reevaluation occurs, it will not result in changes.
eolivelli
reviewed
Mar 5, 2019
|
addExclusion is generated code in core maven. That’s also why Exclusions don’t have an equals() implementation. I’d add a test case if I could come up with a repro case that triggered on its own. I added some discussion in the JIRA. |
rvesse
approved these changes
Mar 5, 2019
|
Note, that the fix in #15 looks like the fix for why exclusions get reevaluated. Even if that is merged, this fix should be taken too for correctness. |
maobaolong
approved these changes
Oct 19, 2020
neo-technology-build-agent
pushed a commit
to neo4j/neo4j
that referenced
this pull request
Dec 14, 2020
…n shade bug A bug in the Maven Shade Plugin may cause an infinite loop (livelock) while creating the dependency reduced pom on parallel builds It seems to happen if the added dependencies are already transitive dependencies Likely fixed by apache/maven-shade-plugin#16
|
I also have this issue when building Apache Camel with a parallel build, similar to the above example. |
neo-technology-build-agent
pushed a commit
to neo4j/neo4j
that referenced
this pull request
Jun 17, 2021
…n shade bug A bug in the Maven Shade Plugin may cause an infinite loop (livelock) while creating the dependency reduced pom on parallel builds It seems to happen if the added dependencies are already transitive dependencies Likely fixed by apache/maven-shade-plugin#16
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Although I don't fully understand the scenarios where we re-evaluate
the exclusions of a dependency, I do know that if we do, we will add
them again, leading to a false indication that the dependency list has
changed, leading to a regeneration and re-evaluation of the list,
which then continues indefinitely, as the the same exclusions are
added again and again.
To address the leaf problem, let's ensure that we never add an
exclusion that is already present. That way, even if reevaluation
occurs, it will not result in changes.