On Wed, Aug 17, 2016 at 10:16 PM, Curtis Rueden <ctrue...@wisc.edu> wrote:
> 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? > I was trying to show the inconsistency. If you have foo in a bom it doesn't work but if you override the dependency manually (or override the version for foo in properties) it works. If we can't no longer override a version from the parent using a property that's really bad because Spring Boot does that a lot. Is there a link to an issue so that I can try on other projects? Thanks! S. > > 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 > > > > >
