Am 03/10/17 um 23:33 schrieb Christian Schulte: > Am 03/10/17 um 20:16 schrieb Robert Scholte: >> On Fri, 10 Mar 2017 16:47:45 +0100, Christian Schulte <c...@schulte.it> >> wrote: >> >>> Am 03/10/17 um 10:42 schrieb Robert Scholte: >>>> Having a closer look at this commit, I actually don't like the idea that >>>> ModelResolver now supports versionRanges. >>>> IMO the version should always be specific *before* resolving the model. >>>> IIUC correctly this is required to supported version-ranges for managed >>>> dependencies, and that is also something I wonder if we want that. >>>> >>>> Please let us reconsider this commit. >>> >>> You do notice the parent resolution is part of that interface since >>> Maven 3.2.2? I just added the same logic for dependencies to support >>> version ranges in dependency management import declarations. Version >>> ranges are supported everywhere but dependency management _import_ >>> declarations. We already agreed that this is a bug fix and this would >>> have been part of Maven 3.4.0, if we would not have dropped it due to >>> the resolver changes. MNG-4463 has been reported in JIRA 23/Nov/09 >>> 09:39! It's tiresome to discuss things committed in 2014 now. See the >>> 'ModelResolver' interface from Maven 3.2.2. It already contains that >>> logic for 'Parent' model objects. >>> >>> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=045bd1503b70738ffd0fa08e336574107aded801> >>> >>> The new method in 3.5.0 for 'Dependency' model objects will only be used >>> to support version ranges in dependency management _import_ declarations >>> coming in 3.5.1. >>> >>> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=d0911ac57dccb758435cdfd3495121ec9f0ae1b4> >>> >>> Regards, >> >> MNG-4463 is marked for 3.5.1, not for 3.5.0, so this would *not* the the >> moment to commit it. > > Did you read the description of MNG-6182? There is a good reason not to > enhance a public API in a patch release. Just take a look at the history > of the ModelResolver interface. It changed in incompatible ways between > releases. I'd like this to be stable again in the next feature release. > That is 3.5.0 - not 3.5.1. That interface is just an adapter (the > maven-model-builder module does not depend on the resolver). I would not > want to add yet another adapter interface instead of enhancing the > existing one. It's *the* moment to commit this. That's why I added a > method not used by anything at the moment. Maven 3.5.0 still is a > drop-in replacement that way. No one needs to update an implementation. > This will change as soon as something starts to call the new method in > 3.5.1, of course. Just as we add dependencies to Maven 3.0.0 in the > plugins ourselves instead of - say - Maven 3.3.9, I'd like others to be > able to depend on Maven 3.5.0 to compile against that API instead of > 3.5.x. I am repeating the description of MNG-6182 already. I know the > Netbeans IDE is implementing the ModelResolver interface. No one would > expect that interface to change between 3.5.0 and 3.5.1 in a way that > you get a compile time error when compiling against 3.5.1 instead of 3.5.0. > >> >> Let's first push 3.5.0 and give everybody the change to dive into the >> complexity of dependency resolution once we start with 3.5.1 > > What complexity are you talking about? Someone using version ranges in a > dependency management import declaration will not do this without > intention. Maven currently fails the build with an error message. Just > like mentioned in the description of MNG-4463. No one expects a public > API to be enhanced between 3.5.0 and 3.5.1. Are we really discussing the > addition of a new method *not used anywhere*? When in doubt, we should > start a vote on this. > > Regards, >
And for the very same reason I am currently reviewing this commit <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=1d6af709bca616f82db79009d2ebfc8da7724569> so that the changes to the public APIs can be part of 3.5.0 in the same way. Add deprecations to old methods, add new methods but do not change anything else by just not calling the new methods and keep things unchanged. I am very sure we want to ship a stable 3.5.0 API. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
