Hi Christian & Stephane, Thanks for your replies.
Christian Schulte wrote: > I am thinking about introducing model version "4.1.0" in Maven 3.4. I like this idea. Thanks for putting it forward! One question: for POM hierarchies with mixed model versions -- a 4.0.0 POM which imports or extends a 4.1.0 POM or vice versa -- do you foresee any complications? Stephane Nicoll wrote: > Assume "foo" is managed by "pom-base". The minute you want to override > the version of "foo", your bom import scenario falls appart. Why? You simply override the value of foo.version in your POM properties. This worked in Maven 3.3, but is currently broken in 3.4.0-SNAPSHOT. My understanding is that this is a bug distinct from the parent-vs-BOM versioning issue. No? 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 9:57 PM, Christian Schulte <c...@schulte.it> wrote: > Am 08/17/16 um 04:09 schrieb Mark Derricutt: > > On 17 Aug 2016, at 12:32, Christian Schulte wrote: > > > >> There is an easy way to solve this. Maven validates the model version in > >> the POM to match "4.0.0". Based on that version, Maven can decide how to > >> behave. I am thinking about introducing model version "4.1.0" in Maven > >> 3.4. All existing 4.0.0 POMs will work the same way as before. Model > > > > Would the deployed POM be a 4.1.0 or 4.0.0 Model? I seem to recall a > long time ago when we were doing the Google Hangouts discussions about a > mental separation of build/deploy POM. > > Deployed as 4.1.0. Yes, that means POMs will start to appear not useable > with Maven < 3.4. Tools parsing the POMs themselves (not using > maven-model-builder) would need to support that as well. > > > > > If deployed as 4.1.0 then you'd be forcing all consumers of that > dependency to use Maven 3.4.0 itself ( IMHO not in itself a bad idea ), but > that might hurt any consuming applications like Sonar, Jenkins, or other > build tools. > > > > That's the drawback I am seeing as well. It's the same syntax with > different semantics. That's why Maven < 3.4 would need to abort. > Everything < 3.4 cannot provide the behaviour for that model version and > thus must not e.g. silently ignore XML elements leading to e.g. > different dependency trees when used with >= 3.4. It's a question of how > to progress Maven core when it comes to changes in behaviour making > sense. "Has always been that way -> must not change." Means we can never > change anything and must provide new features for changing things (e.g. > keep the import scope the way it always has been and introduce an > include scope with the new behaviour and document the import scope is > considered deprecated). It's not always possible to introduce a change > as a new feature. We recently discussed the addition of some kind of > feature toggles or knobs. That won't work, in my opinion, because Maven > would behave differently based on command line options. It's not > possible to deploy a POM to central whose correct/intended behaviour > depends on a specical command line option in use. I see no other way to > incrementing the model version for such things. Maven needs to know how > to behave solely based on what is in the POM. Nothing syntax related. > > Regards, > -- > Christian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
