Remove unnecessary logic for fixing generated POMs #48721
Merged
Conversation
This file contains hidden or 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
This commit eliminates some custom logic we have in place for post-hoc cleanup of POM files generated by Gradle. There were to main issues this logic was meant to address: First, for dependencies marked as `transitive = false`, Gradle by default creates a "wildcard" exclusion in the generated POM file. It turns out that Ivy didn't handle these types of exclusions well, even though they are perfectly valid and dealt with by Gradle and Maven as expected. We've since confirmed that this issues is indeed resolved in the most recent Ivy release (2.5.0-rc1) so going forward the suggestion to folks consuming Elasticsearch dependencies with Ivy will be to use this version. Second, earlier versions of Gradle would incorrectly assign compile dependencies to the "runtime" scope in the publish POM file. This could cause issues if the dependencies were indeed needed at compile time because their APIs were exposed. This has since been fixed and these dependencies are correctly marked as "compile" scope in the POM. Since these two issues have been resolved in their respective projects we can eliminate this logic and all the supporting code, such as having to create lots of "internal" configurations for tracking transitive dependencies. Signed-off-by: Mark Vieira <[email protected]>
Collaborator
|
Pinging @elastic/es-core-infra (:Core/Infra/Build) |
Contributor
Author
|
@elasticmachine run elasticsearch-ci/2 |
mark-vieira
added a commit
that referenced
this pull request
Oct 31, 2019
This commit eliminates some custom logic we have in place for post-hoc cleanup of POM files generated by Gradle. There were to main issues this logic was meant to address: First, for dependencies marked as `transitive = false`, Gradle by default creates a "wildcard" exclusion in the generated POM file. It turns out that Ivy didn't handle these types of exclusions well, even though they are perfectly valid and dealt with by Gradle and Maven as expected. We've since confirmed that this issues is indeed resolved in the most recent Ivy release (2.5.0-rc1) so going forward the suggestion to folks consuming Elasticsearch dependencies with Ivy will be to use this version. Second, earlier versions of Gradle would incorrectly assign compile dependencies to the "runtime" scope in the publish POM file. This could cause issues if the dependencies were indeed needed at compile time because their APIs were exposed. This has since been fixed and these dependencies are correctly marked as "compile" scope in the POM. Since these two issues have been resolved in their respective projects we can eliminate this logic and all the supporting code, such as having to create lots of "internal" configurations for tracking transitive dependencies.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
This commit eliminates some custom logic we have in place for post-hoc
cleanup of POM files generated by Gradle. There were to main issues this
logic was meant to address:
First, for dependencies marked as
transitive = false, Gradle bydefault creates a "wildcard" exclusion in the generated POM file. It
turns out that Ivy didn't handle these types of exclusions well, even
though they are perfectly valid and dealt with by Gradle and Maven as
expected. We've since confirmed that this issues is indeed resolved in
the most recent Ivy release (2.5.0-rc1) so going forward the suggestion
to folks consuming Elasticsearch dependencies with Ivy will be to use
this version.
Second, earlier versions of Gradle would incorrectly assign compile
dependencies to the "runtime" scope in the publish POM file. This could
cause issues if the dependencies were indeed needed at compile time
because their APIs were exposed. This has since been fixed and these
dependencies are correctly marked as "compile" scope in the POM.
Since these two issues have been resolved in their respective projects
we can eliminate this logic and all the supporting code, such as having
to create lots of "internal" configurations for tracking transitive
dependencies.
Closes #44363