-
Notifications
You must be signed in to change notification settings - Fork 7
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
[Build] Fix duplicated dependency and plugin metadata warnings #212
base: master
Are you sure you want to change the base?
Conversation
@@ -40,7 +40,6 @@ | |||
<dependency> | |||
<groupId>org.eclipse.emf</groupId> | |||
<artifactId>org.eclipse.emf.ecore</artifactId> | |||
<version>${emf-ecore-version}</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of the dependencies (such as this one) are only handled in the main pom.xml file because otherwise some part of the automatic transitive dependency management breaks - it is marked to be removed in the main pom.xml once the issue no longer persists. Therefore I would like to not remove the version numbering here, because that could cause issues in the future when removing that again.
Alternatively, we could move all version management to one central position in general for consistent versions throughout the build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understand. I restored this part.
Alternatively, we could move all version management to one central position in general for consistent versions throughout the build.
Yes it would definitively to have a central dependencyManagement
section used by all (child) projects in the parent pom. But at the same time the current approach is generall also fine. I think there is no major advantage of one or the other.
it is marked to be removed in the main pom.xml once the issue no longer persists.
I assume you are referring to this?
Lines 189 to 190 in 9ee820e
<!-- This dependency management are only here to resolve the broken Maven dependencies of Eclipse artifacts. Should be removed | |
once this ticket is resolved: https://bugs.eclipse.org/bugs/show_bug.cgi?id=567244 --> |
Reading through the issue I think it should be resolved in the meantime, especially the Eclipse platform now uses (mainly) original artifacts from Maven-Central without changes (if possible) and Eclipse-Orbit has been majorly reworked to change artifacts only if they don't provide OSGi metadata.
So latest with #226 it could work to remove the current dependencyManagement
section.
An completely different approach would be to remove the manually maintained pom.xml and use tycho-pomless and let it generate a 'consumer' pom for the build jars that is derived from the dependencies defined in the MANIFEST.MF.
But I think both is better handled in a separate PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a note to remove that section in #226, when I work on it again I will try to do that.
I have not worked with automatically generated poms yet, seems to be a good idea in general if it just replaces the P2 dependencies with working and corresponding Maven dependencies. There are just a few modules that need to be handled differently, because we exclude the SWT dependencies in the language server and replace them with mock code, providing the same API but no functionality.
466b9ba
to
ebe8ce2
Compare
No description provided.