Hi Stephane, Apologies up front for my long reply here. I divided into sections to help break things up.
*== Expected behavior? Or a defect? ==* > if you expect the parent to override something you've defined > in the child, that's not the expected behaviour at all. It certainly _has_ been the expected behavior in my community for the past 5 years. Here is a simplified rundown: - pom-base is the parent POM for everything, locking down plugin versions, and managing common dependency versions. - pom-whiz extends pom-base to manage dependency versions of "whiz" components. - pom-bang extends pom-base to manage dependency versions of "bang" components. - Whiz-based projects extend pom-whiz to gain dependency management of all base and whiz components. - Bang-based projects extend pom-bang to gain dependency management of all base and bang components. - Hybrid projects extend pom-base, and import both pom-whiz and pom-bang, to gain dependency management of all base, whiz and bang components. In this scenario, because we use "release early, release often" style development where components are released individually, it is untenable for the pom-base version to be totally aligned between the most recent pom-base, pom-whiz and pom-bang releases. I.e.: the whiz developers do not want to force releases of bang, and vice versa, just to keep all pom-base versions consistent. With Maven 3.3, all of the above works in a very nice way. The dependency versions of base components come from pom-base, while the dependency versions of whiz components come from the pom-whiz import, and versions of bang components come from pom-bang. Whereas with Maven 3.4, pom-whiz (assuming it is declared before the pom-bang import) wins over the pom-base parent for the base component versions. There are a couple of ways to avoid this: - Add an import of pom-base just before pom-whiz and pom-bang, but this was previously redundant with the parent declaration. - Split out the dependency version management part of each POM -- i.e., create a bom-base, bom-whiz and bom-bang. These boms would all be parentless, and manage only their own respective component sets. Then, hybrid projects which want managed versions of both whiz and bang can continue to import them without inheriting a conflicting set of versions for base components. I like the nice separation of concerns which this second solution offers. But it is more components -- additional complexity which might confuse new developers. *== Still a bug in property overrides? ==* Setting aside the issue above, there still seems to be a bug in property overrides, as illustrated by my earlier gist: https://gist.github.com/ctrueden/a49622e77a65437208feb915a887f929 Here we see that with Maven 3.4.0, setting the imagej.version property to 2.0.0-rc-49 in the <properties> section of the project POM has no effect on the final resolved version of the associated net.imagej:imagej component. Whereas with Maven 3.3.9, setting that property does modify the resolved dependency version. We all agree that this is a bug, right? If this behavior is not changed, I expect it will be the source of frequent bug reports once 3.4.0 is released. *== Build reproducibility ==* One of the beautiful things about Maven is that it tries so hard to foster reproducible builds, despite the fact that it draws heavily from the Internet as needed when building. Releases are immutable, you can pin all used plugins to specific releases, etc., so that when you build your project five years later, the same thing is produced as was originally. But this change in how dependency versions are computed breaks backwards compatibility in the Maven core itself -- something which (as of this writing) cannot be pinned via the POM. I can understand the desire for such core changes between major release versions -- 1.x to 2.x was a big overhaul, and 2.x to 3.x sometimes required massaging of POMs -- but this change is happening in a minor version increment. I do understand that SemVer only promises backwards compatibility of intended behavior, not _all_ behavior. But I think this case is a very gray area. The old behavior allowed to have a single POM which acts as a parent _and_ a BOM -- with the new behavior, this will no longer be practical (see above). *== How to avoid this scenario in the future? ==* I can see that I'm fighting a losing battle here. My community can certainly cut new releases of all our components which are tweaked to work properly with Maven 3.4.0. But I am very concerned about the precedent here: at any point in the future, complex builds which used to work might stop doing so, even without a major version increment, due to future changes in the logic of core Maven. It would be ideal if in the future (something for Maven 4?), as much of this logic as possible could be pushed out of core and into plugins, so that they can be pinned in the POM, to promote better build reproducibility. If you actually made it through this whole thing: thank you for reading. Regards, Curtis -- Curtis Rueden LOCI software architect - http://loci.wisc.edu/software ImageJ2 lead, Fiji maintainer - http://imagej.net/User:Rueden Did you know ImageJ has a forum? http://forum.imagej.net/ On Tue, Aug 16, 2016 at 1:12 PM, Stephane Nicoll <stephane.nic...@gmail.com> wrote: > Hello Curtis, > > I have no opinion on your project (To be honest, I haven't looked in > details yet, quite a large setup) but if you expect the parent to override > something you've defined in the child, that's not the expected behaviour at > all. That's still a problem for you though, I am not denying that. > > Of course, if the issue you're having is some sort of different regression, > we should fix it for sure. > > Thanks, > S. > > On Mon, Aug 15, 2016 at 10:16 PM, Curtis Rueden <ctrue...@wisc.edu> wrote: > > > Hi Stephane, > > > > Why can't we have the best of both worlds? Backwards compatibility, but > > with a "stop sucking" flag which enables the new better behavior? > > > > As I said previously, unless the previous behavior is preserved, all of > my > > communy's existing releases (hundreds of projects, thousands of tags) > will > > no longer build as intended at time of release. > > > > It could be as simple as the required minimum maven version being set to > > 3.4 to trigger the new behavior. > > > > Regards, > > Curtis > > > > On Aug 15, 2016 2:21 PM, "Stephane Nicoll" <stephane.nic...@gmail.com> > > wrote: > > > > > On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <c...@schulte.it> > > wrote: > > > > > > > Am 08/13/16 um 00:28 schrieb Christian Schulte: > > > > > reviewing things. So current state of this is: "That's the > behaviour > > > > > requested and tested during commiting to MNG-5971. Cannot override > > > > > properties? Really requested behaviour? Maybe incorrect. Need to > look > > > at > > > > > it again. There was a reason it got implemented the way it is." > > > > > > > > The current behaviour is on purpose. > > > > > > > > 1. Read POM. > > > > 2. Recursivley read all parent POMs. > > > > 3. Include (import) dependency declarations top-down at each level. > > > > 4. Apply inheritance processing. > > > > > > > > There is no way to use an overridden property value when importing > the > > > > depdency declarations because the import happens before inheritance > > > > processing. Benefit is the imported dependency declarations will be > > > > available to inheritance processing that way. > > > > > > > > > > I agree and I need to draw the attention to the opposite problem (even > if > > > it was already explained here). > > > > > > The spring ecosystem heavily uses BOMs to define the versions for > Spring > > > related modules. We have those for the framework, spring data, spring > > boot > > > and cloud. I took us quite some time to get those BOMs right and this > > > effort lead to the creation of MNG-5971. > > > > > > For those asking for a revert, please consider that without it, the BOM > > > feature is pretty much useless (in the sense it does not enforce > > anything). > > > When you have a dependency management section in a project, you want to > > > make sure that those versions are going to be used in child projects > (and > > > you do so by not specifying any version at all). In a given child > project > > > you can deviate from that rule by overriding the dependency management > > for > > > particular module(s). But it wasn't working with a BOM until now. > > > > > > So, something you couldn't do by importing a BOM is actually working by > > > copy/pasting the content of the BOM in the project! I understand that > > this > > > may feel a regression for those who were relying on the current > behaviour > > > but I think the current status is much more consistent. > > > > > > Cheers, > > > S. > > > > > > > > > > > > > > Regards, > > > > -- > > > > Christian > > > > > > > > > > > > ------------------------------------------------------------ > --------- > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > > > > >
