New Maven Model version (was Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3))

[Paul Benedict <pb...@apache.org>]

Moving this discussion to the dev@ list...

My advice is for the team to introduce the full functional consumption of a
4.1 POM in Maven 4.0. What should go in the 3.x branch is the appropriate
forward-compatible handling -- warning or error -- to allow 3.x users to
receive sensible diagnostic messages.

I see that as the best sole reason to increase Maven's major version. The
3.x has always been held back to using the current POM model. It sounds
like the future is almost here and I wouldn't set the bar any higher for a
Maven 4.0 release. That sounds like the feature that should drive tomorrow.

Cheers,
Paul

On Tue, Aug 16, 2016 at 9:57 PM, Christian Schulte <cs...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>