Le lun. 13 oct. 2025 à 20:49, Vladimir Sitnikov <[email protected]> a écrit :
> >No, depends if another lib does the same and it is common to thave that > >case for commons* as mentionned. > > Please clarify exactly. I do not understand which "another lib" you mean. > if you have your project importing spark and commons-compress, both will define in their dep commons-compress with different versions, how do you resolve it? The maven way is first one wins, if not at dep level it would be at depMgt level which is not better from an user standpoint. > > >Yes but still need the hack I mentionned, ie control the dependencies you > >bring back, no transitive magic > > No. My suggestion does not need the hack you mention, and my suggestion > makes > the resolution automatic from the end user's point of view. > the resolution is already automatic, it is not the one you want but it is defined and doesn't have more pitfalls than your proposal. > > >Also note that what you propose, ie to make it automagically work, is > >literally to enforce end user to review any transitive pom to ensure what > >happens in his pom is what he expected or understand it, sounds a time > >killer, even with AI. > > Please clarify exactly where I propose that everybody should review all the > poms to get the feature working. > You want to consider depMgt which is a project scoped feature to be used by consumers. Without something else (like semver) it can't work for the mentionned reasons. > > >change this order and the > >resolution will defer a lot due to something you do not define yourself > > Please, do not mix "pom order" or "dependency declaration depth" here. > I want to keep this proposal focused. Can we please focus on > <dependencyManagement> in transitive deps here? > Hmm, no cause this means you break all existing pom - and without spoiling we'll not rewrite all poms out there so best case you scope your feature to your own poms. Side note: you can already do it with a custom extension which is the best way to show that your idea is good (or realize it is not sometimes) since it doesn't require maven core hack. Just rewrite the deps based on depMgt in your extension and see what happens in real life with examples more complex than commons. > > >This is wrong, depends on multiple factors, it will be as often 1.0.0 as > >1.1.0 > >Without your suggestion too - as of today. > > Romain, > Could you please execute the test I shared at GitHub? > The current Maven **always** selects 1.0.0 in that example, and it never > selects 1.1.0. > > Here's the link: > > https://github.com/vlsi/jarsplit?tab=readme-ov-file#maven-400-snapshot-8134db6f3c18ab2c68764a5ae05c9e08846b9787 You explicit stated in your pom you want to use v1 (you asked to stop speaking about pom order so i'll not detail this one ;)). > > > > >Can you confirm you assume semver and this is the key which makes it > >working for you and that ultimately depMgt is totally unrelated to the > >solution in terms of conflict resolution? > > Romain, I do not see how semver is connected with Maven resolution. > semver has nothing to do here. > Exactly but it *would* be the only way to make maven selecting > 1.0.0 instead of 1.0.0 when 1.0.0 and 1.1.0 are selected until you do bytecode analyzis - and spoiler alert, we'll not cause it would be too slow on a lot of projects - to guarantee anything. > > Can you confirm Maven 4.0.0-SNAPSHOT resolves 1.0.0 and causes failures in > the runtime? > Yes, invert lib2 and lib1 in your pom and you get [INFO] [stdout] lib-uses-v1: [INFO] [stdout] CoreVersion = 2.0.0 [INFO] [stdout] TarCompressor = 2.0.0 [INFO] [stdout] XzCompressor = 1.0.0 [INFO] [stdout] lib-uses-v2: [INFO] [stdout] CoreVersion = 2.0.0 [INFO] [stdout] TarCompressor = 2.0.0 define depMgt for commons - potentially with a bom from libv2 and it works too side note: exec resolution can differ from dependency plugin (and other plugins) and there can make you assume wrong things for the build: [DEBUG] Collected project artifacts [org.example:lib-uses-v1:jar:1.0.0:compile, org.example:commons-compress:jar:1.0.0:runtime, org.example:lib-uses-v2:jar:2.0.0:compile, org.example:commons-compress-tar:jar:2.0.0:runtime, org.example:commons-compress-core:jar:2.0.0:runtime] [INFO] [stdout] lib-uses-v1: [INFO] [stdout] CoreVersion = 1.0.0 [INFO] [stdout] TarCompressor = 1.0.0 [INFO] [stdout] XzCompressor = 1.0.0 [INFO] [stdout] lib-uses-v2: [INFO] [stdout] CoreVersion = 1.0.0 [INFO] [stdout] TarCompressor = 1.0.0 > Vladimir >
