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 > > > > > > > > >
