[Build] Fix duplicated dependency and plugin metadata warnings#212
[Build] Fix duplicated dependency and plugin metadata warnings#212HannesWell wants to merge 1 commit intokieler:masterfrom
Conversation
| <dependency> | ||
| <groupId>org.eclipse.emf</groupId> | ||
| <artifactId>org.eclipse.emf.ecore</artifactId> | ||
| <version>${emf-ecore-version}</version> |
There was a problem hiding this comment.
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.
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
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.
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.