You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Christian Schulte <cs...@schulte.it> on 2016/08/17 00:32:32 UTC
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Am 08/16/16 um 23:14 schrieb Curtis Rueden:
> 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.
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
version 4.1.0 POMs can only be used by Maven >= 3.4. As soon as a
project starts deploying model version 4.1.0 POMs, Maven < 3.4 will not
support that and abort with an error message. There are other features
we could/should change/introduce in 3.4 based on that model version.
There are no release notes yet. Jut for the 'import' scope there are 3
things we could control based on the model version in 3.4 already.
Nothing of that would be supported by Maven < 3.4 so based on this
discussion, these would need to be reverted as well.
o Version range support for 'import' scope (MNG-4463).
o Relocation support for 'import' scope (MNG-5527).
o Execlusion processing for 'import' scope (MNG-5600).
Put a version range in an 'import' scope declaration, Maven < 3.4 will
abort with an error. Use a relocation in an 'import' scope declaration,
Maven < 3.4 will ignore it. Add execlusions to an 'import' scope
declaration, Maven < 3.4 will ignore it. We added features like these in
the past without incrementing the model version.
In my opinion, everything which has ever been postponed or reverted due
to backwards compatibility should go into 3.4 based on model version
4.1.0. I am not talking about a model change. Just update Maven 3.4 to
validate the model version holds "4.0.0" or "4.1.0" and decide on that
value what to do.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Posted by Christian Schulte <cs...@schulte.it>.
Am 08/19/16 um 17:53 schrieb Curtis Rueden:
> Hi Christian,
>
> This is awesome.
>
>
> == What works ==
>
> With model version 4.0.0, Maven 3.4.0 now behaves exactly as before. And
> the property overriding bug no longer occurs, either. This maintains build
> reproducibility for my projects, for which I am very thankful.
>
> With model version 4.1.0, Maven 3.4.0 complains about my project thusly:
>
> [ERROR] Cannot inherit from parent 'org.scijava:pom-scijava:pom:10.6.0'
> with different model version '4.0.0'. Expected model version '4.0.0'.
Thanks for testing. Error message is misleading. Has been fixed already.
<https://builds.apache.org/job/maven-3.3-release-status-build/>
>
> Followed by many of:
>
> [WARNING] Multiple conflicting imports of dependency ...
This can happen when upgrading from model version 4.0.0 to model version
4.1.0. There is a huge difference in how the effective dependency
management is build. For model version 4.0.0 the import is one of the
very last steps in building the effective model. After inheritance
processing so that parent dependencies have already been merged. In
model version 4.1.0 this is very different. The import is performed
before inheritance processing right where the import is declared. Think
of the import scope for model 4.1.0 being equal to an XInclude. Before
any inheritance processing.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Christian,
This is awesome.
== What works ==
With model version 4.0.0, Maven 3.4.0 now behaves exactly as before. And
the property overriding bug no longer occurs, either. This maintains build
reproducibility for my projects, for which I am very thankful.
With model version 4.1.0, Maven 3.4.0 complains about my project thusly:
[ERROR] Cannot inherit from parent 'org.scijava:pom-scijava:pom:10.6.0'
with different model version '4.0.0'. Expected model version '4.0.0'.
Followed by many of:
[WARNING] Multiple conflicting imports of dependency ...
And after updating all POM ancestors to model 4.1.0, the build succeeds
again, but with the new Maven 3.4.0 behavior.
== What doesn't work ==
The only remaining problem is that with model version 4.1.0, version
property overrides in the POM still do not win over imported BOMs.
That is, with the addition of something like:
$ git diff -U1
diff --git a/pom.xml b/pom.xml
index d04c102..c75eb45 100644
--- a/pom.xml
+++ b/pom.xml
@@ -38,2 +38,3 @@
<main-class>net.imagej.Main</main-class>
+ <imagej.version>2.0.0-rc-49</imagej.version>
</properties>
With model version 4.0.0 the override works:
$ mvn dependency:list|grep 'net.imagej:imagej:'
[INFO] net.imagej:imagej:jar:2.0.0-rc-49:compile
Whereas with model version 4.1.0 there is no override anymore:
$ mvn340 dependency:list|grep 'net.imagej:imagej:'
[WARNING] Multiple conflicting imports of dependency
'net.imagej:imagej:jar' into model '[inherited]:fiji:jar:2.0.0-SNAPSHOT' @
'/Users/curtis/code/fiji/fiji/pom.xml' ('256 : 16,
net.imagej:pom-imagej:15.5.0
/Users/curtis/.m2/repository/net/imagej/pom-imagej/15.5.0/pom-imagej-15.5.0.pom',
'256 : 16, net.imagej:pom-imagej:15.6.0
/Users/curtis/.m2/repository/net/imagej/pom-imagej/15.6.0/pom-imagej-15.6.0.pom').
To resolve this conflict, either declare the dependency directly in the
dependency management of model '[inherited]:fiji:jar:2.0.0-SNAPSHOT' to
override what gets imported or, as of Maven 3.4, rearrange the causing
imports in the inheritance hierarchy to apply standard override logic based
on artifact coordinates. Without resolving this conflict, your build relies
on indeterministic behaviour.
[INFO] net.imagej:imagej:jar:2.0.0-rc-48:compile
I can create an MCVE if that would be helpful; just let me know.
Regards,
Curtis
P.S. Thanks and kudos to Herve Boutemy et al. for the colorized output. So
beautiful!
--
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 Fri, Aug 19, 2016 at 3:05 AM, Christian Schulte <cs...@schulte.it> wrote:
> Am 08/17/16 um 22:16 schrieb Curtis Rueden:
> > 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?
>
> Parent and child need to use the same model version. There is no way to
> support inheritable import scope when a parent is 4.0.0 and a child is
> 4.1.0. Importing a 4.0.0 model into a 4.1.0 and vice versa is possible.
> Current master already has been updated. You can grab a recent
> 3.4.0-SNAPSHOT from here:
> <https://builds.apache.org/view/All/job/maven-3.3-release-status-build/>
>
> It would be great if you could test that existing 4.0.0 projects behave
> exactly as before and that updating the model version to 4.1.0 you get
> the new behaviour. Thanks.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Posted by Christian Schulte <cs...@schulte.it>.
Am 08/17/16 um 22:16 schrieb Curtis Rueden:
> 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?
Parent and child need to use the same model version. There is no way to
support inheritable import scope when a parent is 4.0.0 and a child is
4.1.0. Importing a 4.0.0 model into a 4.1.0 and vice versa is possible.
Current master already has been updated. You can grab a recent
3.4.0-SNAPSHOT from here:
<https://builds.apache.org/view/All/job/maven-3.3-release-status-build/>
It would be great if you could test that existing 4.0.0 projects behave
exactly as before and that updating the model version to 4.1.0 you get
the new behaviour. Thanks.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Posted by Stephane Nicoll <st...@gmail.com>.
On Wed, Aug 17, 2016 at 10:16 PM, Curtis Rueden <ct...@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 <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
> >
> >
>
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Posted by Curtis Rueden <ct...@wisc.edu>.
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 <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
>
>
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Posted by Christian Schulte <cs...@schulte.it>.
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
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Posted by Mark Derricutt <ma...@talios.com>.
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.
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.
--
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Posted by Mark Derricutt <ma...@talios.com>.
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.
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.
--
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt