You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by GitBox <gi...@apache.org> on 2022/03/07 21:35:30 UTC
[GitHub] [maven] cstamas opened a new pull request #689: Example of Maven BOMs
cstamas opened a new pull request #689:
URL: https://github.com/apache/maven/pull/689
The "old" maven-bom -> o.a.m.boms:bom-maven
But this solution provides ALL the transitive
dependencies, a project can import bom-all
and have all the versions set to those used
by given version of Maven.
Also, removed root defined and inherited dependencies,
it is not nice, and was not consistent, as some
modules did redefine them. Now every module
explicitly defines things it depends on.
Ugly:
- repeated depMgt in every submodule, as root POM cannot import bom-all (cycle)
This could be avoided by pushing maven modules "level down", more restructure
of project...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] hboutemy commented on pull request #689: Example of Maven BOMs
Posted by GitBox <gi...@apache.org>.
hboutemy commented on pull request #689:
URL: https://github.com/apache/maven/pull/689#issuecomment-1061178344
what are you trying to solve, please?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] kwin commented on pull request #689: [NOT FOR MERGE] Example of Maven BOMs
Posted by GitBox <gi...@apache.org>.
kwin commented on pull request #689:
URL: https://github.com/apache/maven/pull/689#issuecomment-1061487375
IMHO a BOM should only manage those dependencies which cannot be overridden through the plugin classloader as they are always determined from the Maven Core classloader. That is not the case for https://github.com/apache/maven/pull/689/files#diff-f1748463c332cad4071b21dbd4c295bea0422a9c9bc0dc2bd0547605a62d91d4 as none of the commons packages are exported in https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/maven/extension.xml.
For me the BOM is only useful for Maven plugins, and should only manage those versions which are given by the Maven distribution.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven] rfscholte commented on pull request #689: [NOT FOR MERGE] Example of Maven BOMs
Posted by GitBox <gi...@apache.org>.
rfscholte commented on pull request #689:
URL: https://github.com/apache/maven/pull/689#issuecomment-1061640064
To me a BOM represents only the set of modules of a multimodule, that contain the versions that work together. This should prevent issues with dependency depth/distance which could pull in an unexpected version.
Ideally all multimodules also provide a BOM.
Other dependencies don't belong here, as they should be upgradable/downgradable independent of the BOM.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org