You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Samuel Langlois <sa...@alfresco.com> on 2016/08/12 12:41:29 UTC
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Hello
I noticed a change of behaviour in Maven 3.4, which made one of our builds
fail.
It may be a bit of a corner case, so I'll let someone else decide whether
it's a regression or a bug fix...
We have a submodule where the "parent" pom contains a dependency with
scope=import, but with the version set using a property:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.alfresco</groupId>
<artifactId>alfresco-platform-distribution</artifactId>
<version>${alfresco.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
In the submodule itself, we override this version to be a more recent one:
<properties>
<alfresco.version>5.1.e</alfresco.version>
</properties>
In Maven 3.3 and before, the override is working, and we inherit version
5.1.e of the dependencies.
In maven 3.4, it doesn't any more, so we get older versions of the
dependencies.
It works fine if I move the property override to the parent pom, i.e. the
one where the import dependency is defined.
I've just retested using the latest 3.4.0-SNAPSHOT from 2016-08-06
Thanks for your insight
--
Samuel
--
View this message in context: http://maven.40175.n5.nabble.com/Preleminary-Maven-3-4-0-SNAPSHOT-Testing-Take-3-tp5874456p5877660.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
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/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
Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)
Posted by Christian Schulte <cs...@schulte.it>.
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: 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 Thu, Aug 18, 2016 at 5:24 PM, Curtis Rueden <ct...@wisc.edu> wrote:
> Hi Stephane,
>
>
> In fact, nowhere does it talk about what happens when dependencyManagement
> comes in through both the parent and through imports. It does say, however:
>
I agree that both the doc and the code are missing a piece. I am not
blaming you (or anyone, we did it too!) for creating such project structure
:)
>
> I'm not arguing that "I am right and you are wrong" here—I'm saying that
> the docs make no promises and there is room for doubt here.
Fully agree.
> I am just looking for a solution which will keep everyone's projects
> working as intended while also letting us move Maven forward the way it
> should. It sounds like Christian's proposal to bump the POM model version
> to 4.1.0 may be the way to go.
Sounds good to me!
Cheers,
S.
> Maybe that is a discussion for the dev list?
>
> Regards,
> Curtis
>
> [1]
> https://maven.apache.org/guides/introduction/introduction-to-dependency-
> mechanism.html#Importing_Dependencies
>
> --
> 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 Thu, Aug 18, 2016 at 3:04 AM, Stephane Nicoll <
> stephane.nicoll@gmail.com>
> wrote:
>
> > On Tue, Aug 16, 2016 at 11:14 PM, Curtis Rueden <ct...@wisc.edu>
> wrote:
> >
> > > Hi Stephane,
> > >
> > > Apologies up front for my long reply here. I divided into sections to
> > help
> > > break things up.
> > >
> > >
> > > *== Expected behavior? Or a defect? ==*
> > >
> > > > if you expect the parent to override something you've defined
> > > > in the child, that's not the expected behaviour at all.
> > >
> > > It certainly _has_ been the expected behavior in my community for the
> > past
> > > 5 years. Here is a simplified rundown:
> > >
> > > - pom-base is the parent POM for everything, locking down plugin
> > versions,
> > > and managing common dependency versions.
> > > - pom-whiz extends pom-base to manage dependency versions of "whiz"
> > > components.
> > > - pom-bang extends pom-base to manage dependency versions of "bang"
> > > components.
> > > - Whiz-based projects extend pom-whiz to gain dependency management of
> > all
> > > base and whiz components.
> > > - Bang-based projects extend pom-bang to gain dependency management of
> > all
> > > base and bang components.
> > > - Hybrid projects extend pom-base, and import both pom-whiz and
> pom-bang,
> > > to gain dependency management of all base, whiz and bang components.
> > >
> > > In this scenario, because we use "release early, release often" style
> > > development where components are released individually, it is untenable
> > for
> > > the pom-base version to be totally aligned between the most recent
> > > pom-base, pom-whiz and pom-bang releases. I.e.: the whiz developers do
> > not
> > > want to force releases of bang, and vice versa, just to keep all
> pom-base
> > > versions consistent.
> > >
> >
> > OK, after more coffee I finally managed to get my head around your
> project.
> > The problem is that "pom-whiz" extends from "pom-base". You have a
> scenario
> > where a "whiz" project extends from "pom-base" and then import
> "pom-whiz".
> > Said "pom-whiz", via inheritance, "imports" "pom-base" again.
> >
> > Independently on the issue described in this thread, this setup is broken
> > IMO. I already said we spent a lot of time in Spring land to tune our
> BOMs
> > and one rule of thumb was that you should _never ever_ provide dependency
> > management for something that you're not managing yourself. You should
> let
> > the component responsible for it drive it.
> >
> > Let's take an example in Spring land: Spring Boot is the base for
> > application development: it brings Spring Framework and dependency
> > management for a bunch of third parties. Spring Cloud is built on top of
> > Spring Boot.
> >
> > Initially, the Spring Cloud BOM was (indirectly) importing dependency
> > management from some components managed by Spring Boot. Here's the setup:
> > you have a Spring Boot project (with the spring boot parent that provides
> > you all that's required to build with it and let's say Spring Framework
> > 4.2.2). You decide to include some cloud stuff so you import the
> > "spring-cloud-dependencies" bom. When you do that, that BOM MUST NOT have
> > any opinion about the boot or framework version to use. If you do, cloud
> is
> > basically overriding the decision of the user. Previously, that BOM had
> > some dependency management for boot that would bring, say, Spring
> Framework
> > 4.2.1. So by adding cloud to your project, you know override the
> framework
> > version that the base component provides.
> >
> > I took us a long time to figure this out but we've managed to structure
> our
> > BOM that way and it works quite well. Because we've done so, we're
> already
> > shielded from this problem but we need this in other contexts (typically
> > when a service has to force a dependency change for whatever reason).
> >
> > HTH,
> > S.
> >
> >
> >
> > >
> > > With Maven 3.3, all of the above works in a very nice way. The
> dependency
> > > versions of base components come from pom-base, while the dependency
> > > versions of whiz components come from the pom-whiz import, and versions
> > of
> > > bang components come from pom-bang. Whereas with Maven 3.4, pom-whiz
> > > (assuming it is declared before the pom-bang import) wins over the
> > pom-base
> > > parent for the base component versions.
> > >
> > > There are a couple of ways to avoid this:
> > >
> > > - Add an import of pom-base just before pom-whiz and pom-bang, but this
> > was
> > > previously redundant with the parent declaration.
> > >
> > > - Split out the dependency version management part of each POM -- i.e.,
> > > create a bom-base, bom-whiz and bom-bang. These boms would all be
> > > parentless, and manage only their own respective component sets. Then,
> > > hybrid projects which want managed versions of both whiz and bang can
> > > continue to import them without inheriting a conflicting set of
> versions
> > > for base components.
> > >
> > > I like the nice separation of concerns which this second solution
> offers.
> > > But it is more components -- additional complexity which might confuse
> > new
> > > developers.
> > >
> > >
> > > *== Still a bug in property overrides? ==*
> > >
> > > Setting aside the issue above, there still seems to be a bug in
> property
> > > overrides, as illustrated by my earlier gist:
> > >
> > > https://gist.github.com/ctrueden/a49622e77a65437208feb915a887f929
> > >
> > > Here we see that with Maven 3.4.0, setting the imagej.version property
> to
> > > 2.0.0-rc-49 in the <properties> section of the project POM has no
> effect
> > on
> > > the final resolved version of the associated net.imagej:imagej
> component.
> > > Whereas with Maven 3.3.9, setting that property does modify the
> resolved
> > > dependency version.
> > >
> > > We all agree that this is a bug, right? If this behavior is not
> changed,
> > I
> > > expect it will be the source of frequent bug reports once 3.4.0 is
> > > released.
> > >
> > >
> > > *== Build reproducibility ==*
> > >
> > > One of the beautiful things about Maven is that it tries so hard to
> > foster
> > > reproducible builds, despite the fact that it draws heavily from the
> > > Internet as needed when building. Releases are immutable, you can pin
> all
> > > used plugins to specific releases, etc., so that when you build your
> > > project five years later, the same thing is produced as was originally.
> > But
> > > this change in how dependency versions are computed breaks backwards
> > > compatibility in the Maven core itself -- something which (as of this
> > > writing) cannot be pinned via the POM. I can understand the desire for
> > such
> > > core changes between major release versions -- 1.x to 2.x was a big
> > > overhaul, and 2.x to 3.x sometimes required massaging of POMs -- but
> this
> > > change is happening in a minor version increment.
> > >
> > > I do understand that SemVer only promises backwards compatibility of
> > > intended behavior, not _all_ behavior. But I think this case is a very
> > gray
> > > area. The old behavior allowed to have a single POM which acts as a
> > parent
> > > _and_ a BOM -- with the new behavior, this will no longer be practical
> > (see
> > > above).
> > >
> > >
> > > *== How to avoid this scenario in the future? ==*
> > >
> > > I can see that I'm fighting a losing battle here. My community can
> > > certainly cut new releases of all our components which are tweaked to
> > work
> > > 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.
> > >
> > > If you actually made it through this whole thing: thank you for
> reading.
> > >
> > > 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 1:12 PM, Stephane Nicoll <
> > > stephane.nicoll@gmail.com>
> > > wrote:
> > >
> > > > 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 <ct...@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.nicoll@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <
> cs@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-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 Stephane,
> The problem is that "pom-whiz" extends from "pom-base". You have a
> scenario where a "whiz" project extends from "pom-base" and then
> import "pom-whiz". Said "pom-whiz", via inheritance, "imports"
> "pom-base" again.
Yep, you got it.
> Independently on the issue described in this thread, this setup is
> broken IMO.
If you read the existing documentation on import scope [1], AFAICS, nowhere
does it say that what my projects do is disallowed or broken or discouraged.
In fact, nowhere does it talk about what happens when dependencyManagement
comes in through both the parent and through imports. It does say, however:
"In the example above Z imports the managed dependencies from both X and Y.
However, both X and Y contain dependency a. Here, version 1.1 of a would be
used since X is declared first and a is not declared in Z's
dependencyManagement."
The explicit claim there is that when there are version conflicts between
the same GA in multiple imported POMs, the first imported POM wins. It's
true that the parent is not an imported POM, it is an _inherited_ POM. But
it's declaration comes before the imported POMs. So by similar logic, its
dependency versions were declared first, so they should win.
I'm not arguing that "I am right and you are wrong" here—I'm saying that
the docs make no promises and there is room for doubt here. I do not think
it is a clear-cut situation. And therefore, we cannot simply write off the
breaking change as a "bug-fix".
> I already said we spent a lot of time in Spring land to tune our BOMs
Sure. And so did I. And so did many other projects, I'm sure.
> and one rule of thumb was that you should _never ever_ provide
> dependency management for something that you're not managing
> yourself. You should let the component responsible for it drive it.
I absolutely agree that in retrospect, it is much cleaner to have separate
BOMs, and that is certainly what my projects will do moving forward.
I am just looking for a solution which will keep everyone's projects
working as intended while also letting us move Maven forward the way it
should. It sounds like Christian's proposal to bump the POM model version
to 4.1.0 may be the way to go. Maybe that is a discussion for the dev list?
Regards,
Curtis
[1]
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
--
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 Thu, Aug 18, 2016 at 3:04 AM, Stephane Nicoll <st...@gmail.com>
wrote:
> On Tue, Aug 16, 2016 at 11:14 PM, Curtis Rueden <ct...@wisc.edu> wrote:
>
> > Hi Stephane,
> >
> > Apologies up front for my long reply here. I divided into sections to
> help
> > break things up.
> >
> >
> > *== Expected behavior? Or a defect? ==*
> >
> > > if you expect the parent to override something you've defined
> > > in the child, that's not the expected behaviour at all.
> >
> > It certainly _has_ been the expected behavior in my community for the
> past
> > 5 years. Here is a simplified rundown:
> >
> > - pom-base is the parent POM for everything, locking down plugin
> versions,
> > and managing common dependency versions.
> > - pom-whiz extends pom-base to manage dependency versions of "whiz"
> > components.
> > - pom-bang extends pom-base to manage dependency versions of "bang"
> > components.
> > - Whiz-based projects extend pom-whiz to gain dependency management of
> all
> > base and whiz components.
> > - Bang-based projects extend pom-bang to gain dependency management of
> all
> > base and bang components.
> > - Hybrid projects extend pom-base, and import both pom-whiz and pom-bang,
> > to gain dependency management of all base, whiz and bang components.
> >
> > In this scenario, because we use "release early, release often" style
> > development where components are released individually, it is untenable
> for
> > the pom-base version to be totally aligned between the most recent
> > pom-base, pom-whiz and pom-bang releases. I.e.: the whiz developers do
> not
> > want to force releases of bang, and vice versa, just to keep all pom-base
> > versions consistent.
> >
>
> OK, after more coffee I finally managed to get my head around your project.
> The problem is that "pom-whiz" extends from "pom-base". You have a scenario
> where a "whiz" project extends from "pom-base" and then import "pom-whiz".
> Said "pom-whiz", via inheritance, "imports" "pom-base" again.
>
> Independently on the issue described in this thread, this setup is broken
> IMO. I already said we spent a lot of time in Spring land to tune our BOMs
> and one rule of thumb was that you should _never ever_ provide dependency
> management for something that you're not managing yourself. You should let
> the component responsible for it drive it.
>
> Let's take an example in Spring land: Spring Boot is the base for
> application development: it brings Spring Framework and dependency
> management for a bunch of third parties. Spring Cloud is built on top of
> Spring Boot.
>
> Initially, the Spring Cloud BOM was (indirectly) importing dependency
> management from some components managed by Spring Boot. Here's the setup:
> you have a Spring Boot project (with the spring boot parent that provides
> you all that's required to build with it and let's say Spring Framework
> 4.2.2). You decide to include some cloud stuff so you import the
> "spring-cloud-dependencies" bom. When you do that, that BOM MUST NOT have
> any opinion about the boot or framework version to use. If you do, cloud is
> basically overriding the decision of the user. Previously, that BOM had
> some dependency management for boot that would bring, say, Spring Framework
> 4.2.1. So by adding cloud to your project, you know override the framework
> version that the base component provides.
>
> I took us a long time to figure this out but we've managed to structure our
> BOM that way and it works quite well. Because we've done so, we're already
> shielded from this problem but we need this in other contexts (typically
> when a service has to force a dependency change for whatever reason).
>
> HTH,
> S.
>
>
>
> >
> > With Maven 3.3, all of the above works in a very nice way. The dependency
> > versions of base components come from pom-base, while the dependency
> > versions of whiz components come from the pom-whiz import, and versions
> of
> > bang components come from pom-bang. Whereas with Maven 3.4, pom-whiz
> > (assuming it is declared before the pom-bang import) wins over the
> pom-base
> > parent for the base component versions.
> >
> > There are a couple of ways to avoid this:
> >
> > - Add an import of pom-base just before pom-whiz and pom-bang, but this
> was
> > previously redundant with the parent declaration.
> >
> > - Split out the dependency version management part of each POM -- i.e.,
> > create a bom-base, bom-whiz and bom-bang. These boms would all be
> > parentless, and manage only their own respective component sets. Then,
> > hybrid projects which want managed versions of both whiz and bang can
> > continue to import them without inheriting a conflicting set of versions
> > for base components.
> >
> > I like the nice separation of concerns which this second solution offers.
> > But it is more components -- additional complexity which might confuse
> new
> > developers.
> >
> >
> > *== Still a bug in property overrides? ==*
> >
> > Setting aside the issue above, there still seems to be a bug in property
> > overrides, as illustrated by my earlier gist:
> >
> > https://gist.github.com/ctrueden/a49622e77a65437208feb915a887f929
> >
> > Here we see that with Maven 3.4.0, setting the imagej.version property to
> > 2.0.0-rc-49 in the <properties> section of the project POM has no effect
> on
> > the final resolved version of the associated net.imagej:imagej component.
> > Whereas with Maven 3.3.9, setting that property does modify the resolved
> > dependency version.
> >
> > We all agree that this is a bug, right? If this behavior is not changed,
> I
> > expect it will be the source of frequent bug reports once 3.4.0 is
> > released.
> >
> >
> > *== Build reproducibility ==*
> >
> > One of the beautiful things about Maven is that it tries so hard to
> foster
> > reproducible builds, despite the fact that it draws heavily from the
> > Internet as needed when building. Releases are immutable, you can pin all
> > used plugins to specific releases, etc., so that when you build your
> > project five years later, the same thing is produced as was originally.
> But
> > this change in how dependency versions are computed breaks backwards
> > compatibility in the Maven core itself -- something which (as of this
> > writing) cannot be pinned via the POM. I can understand the desire for
> such
> > core changes between major release versions -- 1.x to 2.x was a big
> > overhaul, and 2.x to 3.x sometimes required massaging of POMs -- but this
> > change is happening in a minor version increment.
> >
> > I do understand that SemVer only promises backwards compatibility of
> > intended behavior, not _all_ behavior. But I think this case is a very
> gray
> > area. The old behavior allowed to have a single POM which acts as a
> parent
> > _and_ a BOM -- with the new behavior, this will no longer be practical
> (see
> > above).
> >
> >
> > *== How to avoid this scenario in the future? ==*
> >
> > I can see that I'm fighting a losing battle here. My community can
> > certainly cut new releases of all our components which are tweaked to
> work
> > 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.
> >
> > If you actually made it through this whole thing: thank you for reading.
> >
> > 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 1:12 PM, Stephane Nicoll <
> > stephane.nicoll@gmail.com>
> > wrote:
> >
> > > 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 <ct...@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.nicoll@gmail.com>
> > > > wrote:
> > > >
> > > > > On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <cs@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-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 Tue, Aug 16, 2016 at 11:14 PM, Curtis Rueden <ct...@wisc.edu> wrote:
> Hi Stephane,
>
> Apologies up front for my long reply here. I divided into sections to help
> break things up.
>
>
> *== Expected behavior? Or a defect? ==*
>
> > if you expect the parent to override something you've defined
> > in the child, that's not the expected behaviour at all.
>
> It certainly _has_ been the expected behavior in my community for the past
> 5 years. Here is a simplified rundown:
>
> - pom-base is the parent POM for everything, locking down plugin versions,
> and managing common dependency versions.
> - pom-whiz extends pom-base to manage dependency versions of "whiz"
> components.
> - pom-bang extends pom-base to manage dependency versions of "bang"
> components.
> - Whiz-based projects extend pom-whiz to gain dependency management of all
> base and whiz components.
> - Bang-based projects extend pom-bang to gain dependency management of all
> base and bang components.
> - Hybrid projects extend pom-base, and import both pom-whiz and pom-bang,
> to gain dependency management of all base, whiz and bang components.
>
> In this scenario, because we use "release early, release often" style
> development where components are released individually, it is untenable for
> the pom-base version to be totally aligned between the most recent
> pom-base, pom-whiz and pom-bang releases. I.e.: the whiz developers do not
> want to force releases of bang, and vice versa, just to keep all pom-base
> versions consistent.
>
OK, after more coffee I finally managed to get my head around your project.
The problem is that "pom-whiz" extends from "pom-base". You have a scenario
where a "whiz" project extends from "pom-base" and then import "pom-whiz".
Said "pom-whiz", via inheritance, "imports" "pom-base" again.
Independently on the issue described in this thread, this setup is broken
IMO. I already said we spent a lot of time in Spring land to tune our BOMs
and one rule of thumb was that you should _never ever_ provide dependency
management for something that you're not managing yourself. You should let
the component responsible for it drive it.
Let's take an example in Spring land: Spring Boot is the base for
application development: it brings Spring Framework and dependency
management for a bunch of third parties. Spring Cloud is built on top of
Spring Boot.
Initially, the Spring Cloud BOM was (indirectly) importing dependency
management from some components managed by Spring Boot. Here's the setup:
you have a Spring Boot project (with the spring boot parent that provides
you all that's required to build with it and let's say Spring Framework
4.2.2). You decide to include some cloud stuff so you import the
"spring-cloud-dependencies" bom. When you do that, that BOM MUST NOT have
any opinion about the boot or framework version to use. If you do, cloud is
basically overriding the decision of the user. Previously, that BOM had
some dependency management for boot that would bring, say, Spring Framework
4.2.1. So by adding cloud to your project, you know override the framework
version that the base component provides.
I took us a long time to figure this out but we've managed to structure our
BOM that way and it works quite well. Because we've done so, we're already
shielded from this problem but we need this in other contexts (typically
when a service has to force a dependency change for whatever reason).
HTH,
S.
>
> With Maven 3.3, all of the above works in a very nice way. The dependency
> versions of base components come from pom-base, while the dependency
> versions of whiz components come from the pom-whiz import, and versions of
> bang components come from pom-bang. Whereas with Maven 3.4, pom-whiz
> (assuming it is declared before the pom-bang import) wins over the pom-base
> parent for the base component versions.
>
> There are a couple of ways to avoid this:
>
> - Add an import of pom-base just before pom-whiz and pom-bang, but this was
> previously redundant with the parent declaration.
>
> - Split out the dependency version management part of each POM -- i.e.,
> create a bom-base, bom-whiz and bom-bang. These boms would all be
> parentless, and manage only their own respective component sets. Then,
> hybrid projects which want managed versions of both whiz and bang can
> continue to import them without inheriting a conflicting set of versions
> for base components.
>
> I like the nice separation of concerns which this second solution offers.
> But it is more components -- additional complexity which might confuse new
> developers.
>
>
> *== Still a bug in property overrides? ==*
>
> Setting aside the issue above, there still seems to be a bug in property
> overrides, as illustrated by my earlier gist:
>
> https://gist.github.com/ctrueden/a49622e77a65437208feb915a887f929
>
> Here we see that with Maven 3.4.0, setting the imagej.version property to
> 2.0.0-rc-49 in the <properties> section of the project POM has no effect on
> the final resolved version of the associated net.imagej:imagej component.
> Whereas with Maven 3.3.9, setting that property does modify the resolved
> dependency version.
>
> We all agree that this is a bug, right? If this behavior is not changed, I
> expect it will be the source of frequent bug reports once 3.4.0 is
> released.
>
>
> *== Build reproducibility ==*
>
> One of the beautiful things about Maven is that it tries so hard to foster
> reproducible builds, despite the fact that it draws heavily from the
> Internet as needed when building. Releases are immutable, you can pin all
> used plugins to specific releases, etc., so that when you build your
> project five years later, the same thing is produced as was originally. But
> this change in how dependency versions are computed breaks backwards
> compatibility in the Maven core itself -- something which (as of this
> writing) cannot be pinned via the POM. I can understand the desire for such
> core changes between major release versions -- 1.x to 2.x was a big
> overhaul, and 2.x to 3.x sometimes required massaging of POMs -- but this
> change is happening in a minor version increment.
>
> I do understand that SemVer only promises backwards compatibility of
> intended behavior, not _all_ behavior. But I think this case is a very gray
> area. The old behavior allowed to have a single POM which acts as a parent
> _and_ a BOM -- with the new behavior, this will no longer be practical (see
> above).
>
>
> *== How to avoid this scenario in the future? ==*
>
> I can see that I'm fighting a losing battle here. My community can
> certainly cut new releases of all our components which are tweaked to work
> 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.
>
> If you actually made it through this whole thing: thank you for reading.
>
> 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 1:12 PM, Stephane Nicoll <
> stephane.nicoll@gmail.com>
> wrote:
>
> > 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 <ct...@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" <st...@gmail.com>
> > > wrote:
> > >
> > > > On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <cs...@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-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 Tue, Aug 16, 2016 at 11:14 PM, Curtis Rueden <ct...@wisc.edu> wrote:
> Hi Stephane,
>
> Apologies up front for my long reply here. I divided into sections to help
> break things up.
>
I appreciate the time you took to reply. I'll focus on the first part for
now.
>
>
> *== Expected behavior? Or a defect? ==*
>
> > if you expect the parent to override something you've defined
> > in the child, that's not the expected behaviour at all.
>
> It certainly _has_ been the expected behavior in my community for the past
> 5 years.
There is a difference between what you actually see in practice and what
you should be seeing (that difference is often, but not always, called a
bug). I understand that this change is a problem for you but the expected
behaviour in Maven is that everything you set in the child overrides what
comes from the parent. And BOM shouldn't be any different. The fact that
this change is actually implemented in 3.4 speaks for itself.
> Here is a simplified rundown:
>
> - pom-base is the parent POM for everything, locking down plugin versions,
> and managing common dependency versions.
> - pom-whiz extends pom-base to manage dependency versions of "whiz"
> components.
> - pom-bang extends pom-base to manage dependency versions of "bang"
> components.
> - Whiz-based projects extend pom-whiz to gain dependency management of all
> base and whiz components.
> - Bang-based projects extend pom-bang to gain dependency management of all
> base and bang components.
> - Hybrid projects extend pom-base, and import both pom-whiz and pom-bang,
> to gain dependency management of all base, whiz and bang components.
>
> In this scenario, because we use "release early, release often" style
> development where components are released individually, it is untenable for
> the pom-base version to be totally aligned between the most recent
> pom-base, pom-whiz and pom-bang releases. I.e.: the whiz developers do not
> want to force releases of bang, and vice versa, just to keep all pom-base
> versions consistent.
>
> With Maven 3.3, all of the above works in a very nice way. The dependency
> versions of base components come from pom-base, while the dependency
> versions of whiz components come from the pom-whiz import, and versions of
> bang components come from pom-bang. Whereas with Maven 3.4, pom-whiz
> (assuming it is declared before the pom-bang import) wins over the pom-base
> parent for the base component versions.
>
There is one gotcha with this approach. Assume "foo" is managed by
"pom-base". The minute you want to override the version of "foo", your bom
import scenario falls appart. But that's ok, you can just copy the
declaration of foo with another version right next to that bom import and
it will work. What strikes me in your description is that you're explaining
how you managed to structure your project, not how it is supposed to work.
If you move the dependencies of "pom-base" to a bom (like all the other
boms) and you import that, you get the same features (and a bit more
flexibility I'd say since you can manage that in the two individual boms
now and still benefit from default values of the parent if you don't want
to override them).
That would make your parent much more stable as well and let all the work
in the two individual BOMs, each having their release cycle.
> There are a couple of ways to avoid this:
>
> - Add an import of pom-base just before pom-whiz and pom-bang, but this was
> previously redundant with the parent declaration.
>
That wouldn't be pom-base. Your parent would become a parent for
pluginsManagement and all the dependencyManagement would move to a separate
BOM that you would manage the same way as the two others. In Spring Boot we
have done both actually (because we don't have the same requirement that
you explain here). "spring-boot-dependencies" is the bom and
"spring-boot-parent" is the parent pom. The latter extends from the former.
If you use the parent you get everything. If you don't, there's still a
separate pom that you can use as a BOM.
I don't know if that's helping
Cheers,
S.
>
> - Split out the dependency version management part of each POM -- i.e.,
> create a bom-base, bom-whiz and bom-bang. These boms would all be
> parentless, and manage only their own respective component sets. Then,
> hybrid projects which want managed versions of both whiz and bang can
> continue to import them without inheriting a conflicting set of versions
> for base components.
>
> I like the nice separation of concerns which this second solution offers.
> But it is more components -- additional complexity which might confuse new
> developers.
>
>
> *== Still a bug in property overrides? ==*
>
> Setting aside the issue above, there still seems to be a bug in property
> overrides, as illustrated by my earlier gist:
>
> https://gist.github.com/ctrueden/a49622e77a65437208feb915a887f929
>
> Here we see that with Maven 3.4.0, setting the imagej.version property to
> 2.0.0-rc-49 in the <properties> section of the project POM has no effect on
> the final resolved version of the associated net.imagej:imagej component.
> Whereas with Maven 3.3.9, setting that property does modify the resolved
> dependency version.
>
> We all agree that this is a bug, right? If this behavior is not changed, I
> expect it will be the source of frequent bug reports once 3.4.0 is
> released.
>
>
> *== Build reproducibility ==*
>
> One of the beautiful things about Maven is that it tries so hard to foster
> reproducible builds, despite the fact that it draws heavily from the
> Internet as needed when building. Releases are immutable, you can pin all
> used plugins to specific releases, etc., so that when you build your
> project five years later, the same thing is produced as was originally. But
> this change in how dependency versions are computed breaks backwards
> compatibility in the Maven core itself -- something which (as of this
> writing) cannot be pinned via the POM. I can understand the desire for such
> core changes between major release versions -- 1.x to 2.x was a big
> overhaul, and 2.x to 3.x sometimes required massaging of POMs -- but this
> change is happening in a minor version increment.
>
> I do understand that SemVer only promises backwards compatibility of
> intended behavior, not _all_ behavior. But I think this case is a very gray
> area. The old behavior allowed to have a single POM which acts as a parent
> _and_ a BOM -- with the new behavior, this will no longer be practical (see
> above).
>
>
> *== How to avoid this scenario in the future? ==*
>
> I can see that I'm fighting a losing battle here. My community can
> certainly cut new releases of all our components which are tweaked to work
> 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.
>
> If you actually made it through this whole thing: thank you for reading.
>
> 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 1:12 PM, Stephane Nicoll <
> stephane.nicoll@gmail.com>
> wrote:
>
> > 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 <ct...@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" <st...@gmail.com>
> > > wrote:
> > >
> > > > On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <cs...@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-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/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 Curtis Rueden <ct...@wisc.edu>.
Hi Stephane,
Apologies up front for my long reply here. I divided into sections to help
break things up.
*== Expected behavior? Or a defect? ==*
> if you expect the parent to override something you've defined
> in the child, that's not the expected behaviour at all.
It certainly _has_ been the expected behavior in my community for the past
5 years. Here is a simplified rundown:
- pom-base is the parent POM for everything, locking down plugin versions,
and managing common dependency versions.
- pom-whiz extends pom-base to manage dependency versions of "whiz"
components.
- pom-bang extends pom-base to manage dependency versions of "bang"
components.
- Whiz-based projects extend pom-whiz to gain dependency management of all
base and whiz components.
- Bang-based projects extend pom-bang to gain dependency management of all
base and bang components.
- Hybrid projects extend pom-base, and import both pom-whiz and pom-bang,
to gain dependency management of all base, whiz and bang components.
In this scenario, because we use "release early, release often" style
development where components are released individually, it is untenable for
the pom-base version to be totally aligned between the most recent
pom-base, pom-whiz and pom-bang releases. I.e.: the whiz developers do not
want to force releases of bang, and vice versa, just to keep all pom-base
versions consistent.
With Maven 3.3, all of the above works in a very nice way. The dependency
versions of base components come from pom-base, while the dependency
versions of whiz components come from the pom-whiz import, and versions of
bang components come from pom-bang. Whereas with Maven 3.4, pom-whiz
(assuming it is declared before the pom-bang import) wins over the pom-base
parent for the base component versions.
There are a couple of ways to avoid this:
- Add an import of pom-base just before pom-whiz and pom-bang, but this was
previously redundant with the parent declaration.
- Split out the dependency version management part of each POM -- i.e.,
create a bom-base, bom-whiz and bom-bang. These boms would all be
parentless, and manage only their own respective component sets. Then,
hybrid projects which want managed versions of both whiz and bang can
continue to import them without inheriting a conflicting set of versions
for base components.
I like the nice separation of concerns which this second solution offers.
But it is more components -- additional complexity which might confuse new
developers.
*== Still a bug in property overrides? ==*
Setting aside the issue above, there still seems to be a bug in property
overrides, as illustrated by my earlier gist:
https://gist.github.com/ctrueden/a49622e77a65437208feb915a887f929
Here we see that with Maven 3.4.0, setting the imagej.version property to
2.0.0-rc-49 in the <properties> section of the project POM has no effect on
the final resolved version of the associated net.imagej:imagej component.
Whereas with Maven 3.3.9, setting that property does modify the resolved
dependency version.
We all agree that this is a bug, right? If this behavior is not changed, I
expect it will be the source of frequent bug reports once 3.4.0 is released.
*== Build reproducibility ==*
One of the beautiful things about Maven is that it tries so hard to foster
reproducible builds, despite the fact that it draws heavily from the
Internet as needed when building. Releases are immutable, you can pin all
used plugins to specific releases, etc., so that when you build your
project five years later, the same thing is produced as was originally. But
this change in how dependency versions are computed breaks backwards
compatibility in the Maven core itself -- something which (as of this
writing) cannot be pinned via the POM. I can understand the desire for such
core changes between major release versions -- 1.x to 2.x was a big
overhaul, and 2.x to 3.x sometimes required massaging of POMs -- but this
change is happening in a minor version increment.
I do understand that SemVer only promises backwards compatibility of
intended behavior, not _all_ behavior. But I think this case is a very gray
area. The old behavior allowed to have a single POM which acts as a parent
_and_ a BOM -- with the new behavior, this will no longer be practical (see
above).
*== How to avoid this scenario in the future? ==*
I can see that I'm fighting a losing battle here. My community can
certainly cut new releases of all our components which are tweaked to work
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.
If you actually made it through this whole thing: thank you for reading.
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 1:12 PM, Stephane Nicoll <st...@gmail.com>
wrote:
> 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 <ct...@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" <st...@gmail.com>
> > wrote:
> >
> > > On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <cs...@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-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>.
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 <ct...@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" <st...@gmail.com>
> wrote:
>
> > On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <cs...@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-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 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" <st...@gmail.com>
wrote:
> On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <cs...@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-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 Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte <cs...@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-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/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.
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/12/16 um 20:11 schrieb Curtis Rueden:
> Hi Christian,
>
> Thank you very much for looking at my example, and your speedy reply.
>
>> Can you please add your objections to MNG-5971 in JIRA.
>
> Done. I also added the same comments to MNG-6079, which I believe is a
> legitimate regression caused by the fixing of MNG-5971.
Commenting on this @MNG-5971 will make JIRA send emails to the parties
involved in that change. So let's see what they have to say about it.
Maybe you have uncovered an issue no-one has noticed during testing.
>
>>> 2) I do not know how to restructure my components for Maven 3.4.0 to
>>> avoid this problem.
>>
>> Simply by applying inheritance. This is what MNG-5971 is about.
>> Imported dependencies have not been part of inheritance processing
>> prior 3.4 but should. Think about the import scope as a way to just
>> include some dependencies in the dependency management where it is
>> used.
> ...
>> You could just update your poms to make use of inheritance. You would
>> just need to declare the dependency in question in the dependency
>> management of the inheritance level in question.
>
> So if I understand correctly: with the new approach, it is no longer
> possible to override the version of a transitive dependency, without adding
> it as a direct dependency of the current project, even though it actually
> isn't? Or is there still a way
It's just about overriding properties. If there are no properties to
interpolate in the current inheritance level, the expression will be
inherited. Regarding the example project attached to MNG-6079: If you
would remove the property 'surefire.version' completely from
'parent-pom.xml', the interpolation would happen at the correct level
(in 'pom.xml') with the value setup in 'pom.xml'. You could add a
profile to 'pom.xml' overriding the property to something else in that
pom. There may be bugs in the current interpolation logic. I am still
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."
>
> I would like to draw your attention to another use case my community has.
> Check out this profile:
>
> * https://github.com/fiji/pom-fiji/blob/pom-fiji-24.3.0/pom.xml#L1064-L1214
>
> It overrides all managed version properties in the BOM to LATEST, to make
> snapshot coupling in IDEs (particularly Eclipse) less painful.
See above. Overriding properties at the same inheritance level nothing
should have changed.
> My understanding of the MNG-5971 change is that the above hack will no
> longer work. And I cannot see any new way to achieve something similar? How
> do other projects achieve temporary snapshot couplings during development,
> without requiring changes to the local dev environment?
>
> Yet another wrinkle which occurs to me: What about cases where the version
> property is used in some configuration somewhere, _besides_ in the
> dependency declaration? For example, consider the following configuration
> block:
>
> <plugin>
> <artifactId>maven-jar-plugin</artifactId>
> <version>3.0.2</version>
> <configuration>
> <archive>
> <manifestEntries>
> <!-- Add SciJava Common version to the JAR manifest. -->
> <SciJava-Common-Version>${scijava-common.version}</SciJava-Common-Version>
> </manifestEntries>
> </archive>
> </configuration>
> </plugin>
>
> Of course, the above example is a little contrived, but surely there are
> real builds in the wild where a dependency version is fed to a plugin
> configuration somewhere? Won't these versions now be "wrong" from the
> perspective of the human -- not matching what is actually in the dependency
> tree?
>
>> It will also fix builds.
>
> My main beef is the breakage of backwards compatibility. All my old builds
> which used to work will no longer work. Wouldn't it be better to have some
> new configuration to achieve the desired result for previously broken
> builds? Maven component releases are immutable -- I can't go back and fix
> all my old releases to work with Maven 3.4.0, ever.
In Maven 2, things like the 'import' scope got introduced in patch
releases and were just documented. See the "Dependency Scope" section
here:
<http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html>
import (only available in Maven 2.0.9 or later)
So in my opinion we should have introduced that 'include' scope in 3.4.
It's a minor version increment already, not a patch release. The import
scope as it got introduced in 2.0.9 has been corrected in 3.4, however.
It's like supporting something behaving incorrectly forever and
introduce the corrections as a new feature. To not confuse users, this
is all only about how the "import" scope is implemented. It got changed
from "import dependency declarations not already available in the
effective model after building that effective model" to "include the
dependency delcarations of the imported POM where the import occurs and
then build the effective model with that".
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>.
The code in question is in class 'DefaultModelBuilder'. Everything is
done by those two methods:
public ModelBuildingResult build( ModelBuildingRequest request )
public ModelBuildingResult build( ModelBuildingRequest request,
ModelBuildingResult result )
Called in that order.
<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java;h=93c62d09413c8880521983fb735c4cc503328570;hb=HEAD#l259>
<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java;h=93c62d09413c8880521983fb735c4cc503328570;hb=HEAD#l447>
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,
Thank you very much for looking at my example, and your speedy reply.
> Can you please add your objections to MNG-5971 in JIRA.
Done. I also added the same comments to MNG-6079, which I believe is a
legitimate regression caused by the fixing of MNG-5971.
> > 2) I do not know how to restructure my components for Maven 3.4.0 to
> > avoid this problem.
>
> Simply by applying inheritance. This is what MNG-5971 is about.
> Imported dependencies have not been part of inheritance processing
> prior 3.4 but should. Think about the import scope as a way to just
> include some dependencies in the dependency management where it is
> used.
...
> You could just update your poms to make use of inheritance. You would
> just need to declare the dependency in question in the dependency
> management of the inheritance level in question.
So if I understand correctly: with the new approach, it is no longer
possible to override the version of a transitive dependency, without adding
it as a direct dependency of the current project, even though it actually
isn't? Or is there still a way?
I would like to draw your attention to another use case my community has.
Check out this profile:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.3.0/pom.xml#L1064-L1214
It overrides all managed version properties in the BOM to LATEST, to make
snapshot coupling in IDEs (particularly Eclipse) less painful.
My understanding of the MNG-5971 change is that the above hack will no
longer work. And I cannot see any new way to achieve something similar? How
do other projects achieve temporary snapshot couplings during development,
without requiring changes to the local dev environment?
Yet another wrinkle which occurs to me: What about cases where the version
property is used in some configuration somewhere, _besides_ in the
dependency declaration? For example, consider the following configuration
block:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<configuration>
<archive>
<manifestEntries>
<!-- Add SciJava Common version to the JAR manifest. -->
<SciJava-Common-Version>${scijava-common.version}</SciJava-Common-Version>
</manifestEntries>
</archive>
</configuration>
</plugin>
Of course, the above example is a little contrived, but surely there are
real builds in the wild where a dependency version is fed to a plugin
configuration somewhere? Won't these versions now be "wrong" from the
perspective of the human -- not matching what is actually in the dependency
tree?
> It will also fix builds.
My main beef is the breakage of backwards compatibility. All my old builds
which used to work will no longer work. Wouldn't it be better to have some
new configuration to achieve the desired result for previously broken
builds? Maven component releases are immutable -- I can't go back and fix
all my old releases to work with Maven 3.4.0, ever.
Thanks,
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 Fri, Aug 12, 2016 at 12:46 PM, Christian Schulte <cs...@schulte.it> wrote:
> Am 12.08.2016 um 19:16 schrieb Curtis Rueden:
>
>> Hi all,
>>
>> Concerned by this thread, I did some tests. And I have to say, the new
>> Maven 3.4.0 dependency resolution rules seem like a step backwards.
>>
>> == REAL-WORLD EXAMPLE ==
>>
>> Consider the following project:
>> https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d61475
>> 9fb6e78e359d4f/pom.xml
>>
>> Amongst many other dependencies, this project has:
>>
>> <dependency>
>> <groupId>ca.mcgill</groupId>
>> <artifactId>Sholl_Analysis</artifactId>
>> <scope>runtime</scope>
>> </dependency>
>>
>> This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
>>
>> * https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
>> * https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
>>
>> <properties>
>> <!-- Sholl Analysis - https://github.com/tferr/ASA -->
>> <Sholl_Analysis.version>3.6.2</Sholl_Analysis.version>
>> </properties> ...
>> <dependencyManagement>
>> <dependencies>
>> <!-- Sholl Analysis - https://github.com/tferr/ASA -->
>> <dependency> <groupId>ca.mcgill</groupId>
>> <artifactId>Sholl_Analysis</artifactId>
>> <version>${Sholl_Analysis.version}</version> </dependency>
>> </dependencies>
>> </dependencyManagement>
>>
>> With Maven 3.3.9, we have:
>>
>> $ mvn dependency:list|grep Sholl
>> [INFO] ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
>>
>> But with Maven 3.4.0-20160806.181437-172, we get:
>>
>> $ mvn dependency:list|grep Sholl
>> [INFO] ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
>>
>> !!!
>>
>> I believe this surprising behavior is caused by the fact that the toplevel
>> fiji POM needs to also include other BOMs via import scope:
>>
>> *
>> https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d61475
>> 9fb6e78e359d4f/pom.xml#L49-L68
>>
>> <dependencyManagement>
>> <dependencies>
>> <!-- BigDataViewer BOM -->
>> <dependency>
>> <groupId>sc.fiji</groupId>
>> <artifactId>pom-bigdataviewer</artifactId>
>> <version>${pom-bigdataviewer.version}</version>
>> <type>pom</type>
>> <scope>import</scope>
>> </dependency>
>> <!-- TrakEM2 BOM -->
>> <dependency>
>> <groupId>sc.fiji</groupId>
>> <artifactId>pom-trakem2</artifactId>
>> <version>${pom-trakem2.version}</version>
>> <type>pom</type>
>> <scope>import</scope>
>> </dependency>
>> </dependencies>
>> </dependencyManagement>
>>
>> The version of pom-bigdataviewer is 3.2.0:
>> * https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
>>
>> Which extends pom-fiji version 22.3.0 instead of 24.1.0:
>> *
>> https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-
>> bigdataviewer-3.2.0/pom.xml#L5-L9
>>
>> And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
>> * https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
>>
>> == GIST OF THE PROBLEM ==
>>
>> So, with Maven 3.4.0, dependency management brought in from import scope
>> is
>> now trumping that brought in from the parent POM itself.
>>
>
> That's exactly the issue we have solved. The dependency management at
> child level did not override the parent but it should as everything else
> does.
>
> - IMHO, it violates the Principle of Least Astonishment.
>>
>
> No. It's the opposite. You would expect a child dependency management to
> override the parent and not the other way around.
>
> - It is now more complicated to compose together multiple "subtrees" of
>> components into a final application which needs to inherit multiple BOMs
>> from these subtrees.
>>
>
> That's become easier now as you can override things at child level you
> could not have overriden before.
>
> - It is now not possible to override version properties _in the POM itself_
>> to trump the dependencyManagement versions.
>>
>
> That's correct. That's why I wanted to not change the import scope and
> introduce a new scope called include.
>
>
>> But strangely, you _can_ still override the version property on the CLI
>> via
>> -DSholl_Analysis.version=x.y.z.
>>
>
> Because that CLI property will override it the parent as well.
>
> I understand and appreciate that I am naive of the deepest nuances of the
>> Maven project model and how it gets synthesized. But:
>>
>> 1) The above behavior will break all of my projects.
>> 2) I do not know how to restructure my components for Maven 3.4.0 to avoid
>> this problem.
>>
>
> Simply by applying inheritance. This is what MNG-5971 is about. Imported
> dependencies have not been part of inheritance processing prior 3.4 but
> should. Think about the import scope as a way to just include some
> dependencies in the dependency management where it is used.
>
> My vote would be to revert to the old behavior, which seems better to me.
>> However, if this behavior really must be changed, I would suggest pushing
>> it till Maven 4, since it will surely break a lot of existing builds.
>>
>
> It will also fix builds. You could just update your poms to make use of
> inheritance. You would just need to declare the dependency in question in
> the dependency management of the inheritance level in question.
>
>
> 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 12.08.2016 um 19:16 schrieb Curtis Rueden:
> Hi all,
>
> Concerned by this thread, I did some tests. And I have to say, the new
> Maven 3.4.0 dependency resolution rules seem like a step backwards.
>
> == REAL-WORLD EXAMPLE ==
>
> Consider the following project:
> https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
>
> Amongst many other dependencies, this project has:
>
> <dependency>
> <groupId>ca.mcgill</groupId>
> <artifactId>Sholl_Analysis</artifactId>
> <scope>runtime</scope>
> </dependency>
>
> This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
>
> * https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
> * https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
>
> <properties>
> <!-- Sholl Analysis - https://github.com/tferr/ASA -->
> <Sholl_Analysis.version>3.6.2</Sholl_Analysis.version>
> </properties> ...
> <dependencyManagement>
> <dependencies>
> <!-- Sholl Analysis - https://github.com/tferr/ASA -->
> <dependency> <groupId>ca.mcgill</groupId>
> <artifactId>Sholl_Analysis</artifactId>
> <version>${Sholl_Analysis.version}</version> </dependency>
> </dependencies>
> </dependencyManagement>
>
> With Maven 3.3.9, we have:
>
> $ mvn dependency:list|grep Sholl
> [INFO] ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
>
> But with Maven 3.4.0-20160806.181437-172, we get:
>
> $ mvn dependency:list|grep Sholl
> [INFO] ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
>
> !!!
>
> I believe this surprising behavior is caused by the fact that the toplevel
> fiji POM needs to also include other BOMs via import scope:
>
> *
> https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
>
> <dependencyManagement>
> <dependencies>
> <!-- BigDataViewer BOM -->
> <dependency>
> <groupId>sc.fiji</groupId>
> <artifactId>pom-bigdataviewer</artifactId>
> <version>${pom-bigdataviewer.version}</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> <!-- TrakEM2 BOM -->
> <dependency>
> <groupId>sc.fiji</groupId>
> <artifactId>pom-trakem2</artifactId>
> <version>${pom-trakem2.version}</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
>
> The version of pom-bigdataviewer is 3.2.0:
> * https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
>
> Which extends pom-fiji version 22.3.0 instead of 24.1.0:
> *
> https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
>
> And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
> * https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
>
> == GIST OF THE PROBLEM ==
>
> So, with Maven 3.4.0, dependency management brought in from import scope is
> now trumping that brought in from the parent POM itself.
That's exactly the issue we have solved. The dependency management at
child level did not override the parent but it should as everything else
does.
> - IMHO, it violates the Principle of Least Astonishment.
No. It's the opposite. You would expect a child dependency management to
override the parent and not the other way around.
> - It is now more complicated to compose together multiple "subtrees" of
> components into a final application which needs to inherit multiple BOMs
> from these subtrees.
That's become easier now as you can override things at child level you
could not have overriden before.
> - It is now not possible to override version properties _in the POM itself_
> to trump the dependencyManagement versions.
That's correct. That's why I wanted to not change the import scope and
introduce a new scope called include.
>
> But strangely, you _can_ still override the version property on the CLI via
> -DSholl_Analysis.version=x.y.z.
Because that CLI property will override it the parent as well.
> I understand and appreciate that I am naive of the deepest nuances of the
> Maven project model and how it gets synthesized. But:
>
> 1) The above behavior will break all of my projects.
> 2) I do not know how to restructure my components for Maven 3.4.0 to avoid
> this problem.
Simply by applying inheritance. This is what MNG-5971 is about. Imported
dependencies have not been part of inheritance processing prior 3.4 but
should. Think about the import scope as a way to just include some
dependencies in the dependency management where it is used.
> My vote would be to revert to the old behavior, which seems better to me.
> However, if this behavior really must be changed, I would suggest pushing
> it till Maven 4, since it will surely break a lot of existing builds.
It will also fix builds. You could just update your poms to make use of
inheritance. You would just need to declare the dependency in question
in the dependency management of the inheritance level in question.
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,
Thank you for all your time and effort.
> Could you please test properties can correctly be overridden again in
> the latest 3.4.0-SNAPSHOT
In my tests, setting a version property in the POM still does not override
the version as it did in 3.3.9:
https://gist.github.com/ctrueden/a49622e77a65437208feb915a887f929
(Apologies if I misunderstood what you were asking to be tested.)
Regards,
Curtis
P.S. The "Multiple conflicting imports" warning is very helpful.
--
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 12, 2016 at 7:03 PM, Christian Schulte <cs...@schulte.it> wrote:
> Could you please test properties can correctly be overridden again in
> the latest 3.4.0-SNAPSHOT available from
> <https://builds.apache.org/job/maven-3.3-release-status-build/>. It
> should have been fixed by this commit
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 814b5166123c54b21545038038536063ce8dba1c>.
>
> 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>.
Could you please test properties can correctly be overridden again in
the latest 3.4.0-SNAPSHOT available from
<https://builds.apache.org/job/maven-3.3-release-status-build/>. It
should have been fixed by this commit
<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=814b5166123c54b21545038038536063ce8dba1c>.
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>.
Can you please add your objections to MNG-5971 in JIRA. Maybe by copy
and pasting your email. Reverting to the old behaviour is problematic
and most of the users having taken part in that discussion will disagree
with you, I think. The issue has been filed due to real-world problems.
There are no release notes available yet. I will take a look at your
example projects now. Maybe there are just some corner-cases we just
need to mention in the release notes.
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 all,
Concerned by this thread, I did some tests. And I have to say, the new
Maven 3.4.0 dependency resolution rules seem like a step backwards.
== REAL-WORLD EXAMPLE ==
Consider the following project:
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
<dependency>
<groupId>ca.mcgill</groupId>
<artifactId>Sholl_Analysis</artifactId>
<scope>runtime</scope>
</dependency>
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
<properties>
<!-- Sholl Analysis - https://github.com/tferr/ASA -->
<Sholl_Analysis.version>3.6.2</Sholl_Analysis.version>
</properties> ...
<dependencyManagement>
<dependencies>
<!-- Sholl Analysis - https://github.com/tferr/ASA -->
<dependency> <groupId>ca.mcgill</groupId>
<artifactId>Sholl_Analysis</artifactId>
<version>${Sholl_Analysis.version}</version> </dependency>
</dependencies>
</dependencyManagement>
With Maven 3.3.9, we have:
$ mvn dependency:list|grep Sholl
[INFO] ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
But with Maven 3.4.0-20160806.181437-172, we get:
$ mvn dependency:list|grep Sholl
[INFO] ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
!!!
I believe this surprising behavior is caused by the fact that the toplevel
fiji POM needs to also include other BOMs via import scope:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
<dependencyManagement>
<dependencies>
<!-- BigDataViewer BOM -->
<dependency>
<groupId>sc.fiji</groupId>
<artifactId>pom-bigdataviewer</artifactId>
<version>${pom-bigdataviewer.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- TrakEM2 BOM -->
<dependency>
<groupId>sc.fiji</groupId>
<artifactId>pom-trakem2</artifactId>
<version>${pom-trakem2.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
== GIST OF THE PROBLEM ==
So, with Maven 3.4.0, dependency management brought in from import scope is
now trumping that brought in from the parent POM itself. This is
problematic because:
- IMHO, it violates the Principle of Least Astonishment.
- It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs
from these subtrees.
- It is now not possible to override version properties _in the POM itself_
to trump the dependencyManagement versions.
But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z.
I understand and appreciate that I am naive of the deepest nuances of the
Maven project model and how it gets synthesized. But:
1) The above behavior will break all of my projects.
2) I do not know how to restructure my components for Maven 3.4.0 to avoid
this problem.
My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing
it till Maven 4, since it will surely break a lot of existing builds.
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 Fri, Aug 12, 2016 at 10:58 AM, Christian Schulte <cs...@schulte.it> wrote:
> Am 08/12/16 um 14:41 schrieb Samuel Langlois:
> > Hello
> >
> > I noticed a change of behaviour in Maven 3.4, which made one of our
> builds
> > fail.
> > It may be a bit of a corner case, so I'll let someone else decide whether
> > it's a regression or a bug fix...
>
> You can read all about it here:
>
> <https://issues.apache.org/jira/browse/MNG-5971>
>
> 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/12/16 um 14:41 schrieb Samuel Langlois:
> Hello
>
> I noticed a change of behaviour in Maven 3.4, which made one of our builds
> fail.
> It may be a bit of a corner case, so I'll let someone else decide whether
> it's a regression or a bug fix...
You can read all about it here:
<https://issues.apache.org/jira/browse/MNG-5971>
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/15/16 um 20:49 schrieb David Hoffer:
> I will try to test with 3.2.2 but I can confirm that 3.2.5 does not have
> this behavior as that is our official build version for this application.
> I am trying to move to latest maven version and discovered this.
A project to reproduce this would be great.
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 David Hoffer <dh...@gmail.com>.
I will try to test with 3.2.2 but I can confirm that 3.2.5 does not have
this behavior as that is our official build version for this application.
I am trying to move to latest maven version and discovered this.
Regards,
-Dave
On Mon, Aug 15, 2016 at 12:40 PM, Christian Schulte <cs...@schulte.it> wrote:
> Am 08/15/16 um 20:30 schrieb David Hoffer:
> > I'm testing with build 110 and have found an error with one of our
> current
> > builds (it works through 3.3.9). It's a bit of an odd-ball case.
> >
> > We have a child parent pom module that has several children if its own.
> > One of those child modules uses a variable for the module name. E.g.
> >
> > <modules>
> > <module>exchange</module>
> > <module>asw</module>
> > <module>third-party-jax-ws-model</module>
> > <module>${jmsedm-artifactId.new}</module>
> > <module>third-party-enterprise-messaging</module>
> > <module>third-party-ccsds</module>
> > </modules>
> >
> > In the parent pom we have that property defined as:
> >
> > <jmsedm.version>3.3.0</jmsedm.version>
> > <jmsedm-artifactId.new>jmsedm-v${jmsedm.version}</jmsedm-artifactId.new>
> >
> > With the 110 build we get this error:
> >
> > [ERROR] The project com.jms.external:third-party:11.x-SNAPSHOT
> > (C:\svn\trunk\third-party\pom.xml) has 1 error
> > [ERROR] Child module C:\svn\trunk\third-party\${
> jmsedm-artifactId.new}
> > of C:\svn\trunk\third-party\pom.xml does not exist
> >
> > I've never used variables for module names before so I don't know if this
> > is a regression or if it's intended to prevent this going forward, but it
> > used to work fine.
> >
>
> Could you please provide an example project to reproduce this with. If
> not possible, could you please test the project using Maven 3.2.2 and
> see if that version behaves the same way Maven 3.4.0-SNAPSHOT does?
>
> 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/15/16 um 20:30 schrieb David Hoffer:
> I'm testing with build 110 and have found an error with one of our current
> builds (it works through 3.3.9). It's a bit of an odd-ball case.
>
> We have a child parent pom module that has several children if its own.
> One of those child modules uses a variable for the module name. E.g.
>
> <modules>
> <module>exchange</module>
> <module>asw</module>
> <module>third-party-jax-ws-model</module>
> <module>${jmsedm-artifactId.new}</module>
> <module>third-party-enterprise-messaging</module>
> <module>third-party-ccsds</module>
> </modules>
>
> In the parent pom we have that property defined as:
>
> <jmsedm.version>3.3.0</jmsedm.version>
> <jmsedm-artifactId.new>jmsedm-v${jmsedm.version}</jmsedm-artifactId.new>
>
> With the 110 build we get this error:
>
> [ERROR] The project com.jms.external:third-party:11.x-SNAPSHOT
> (C:\svn\trunk\third-party\pom.xml) has 1 error
> [ERROR] Child module C:\svn\trunk\third-party\${jmsedm-artifactId.new}
> of C:\svn\trunk\third-party\pom.xml does not exist
>
> I've never used variables for module names before so I don't know if this
> is a regression or if it's intended to prevent this going forward, but it
> used to work fine.
>
Could you please provide an example project to reproduce this with. If
not possible, could you please test the project using Maven 3.2.2 and
see if that version behaves the same way Maven 3.4.0-SNAPSHOT does?
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 David Hoffer <dh...@gmail.com>.
I'm testing with build 110 and have found an error with one of our current
builds (it works through 3.3.9). It's a bit of an odd-ball case.
We have a child parent pom module that has several children if its own.
One of those child modules uses a variable for the module name. E.g.
<modules>
<module>exchange</module>
<module>asw</module>
<module>third-party-jax-ws-model</module>
<module>${jmsedm-artifactId.new}</module>
<module>third-party-enterprise-messaging</module>
<module>third-party-ccsds</module>
</modules>
In the parent pom we have that property defined as:
<jmsedm.version>3.3.0</jmsedm.version>
<jmsedm-artifactId.new>jmsedm-v${jmsedm.version}</jmsedm-artifactId.new>
With the 110 build we get this error:
[ERROR] The project com.jms.external:third-party:11.x-SNAPSHOT
(C:\svn\trunk\third-party\pom.xml) has 1 error
[ERROR] Child module C:\svn\trunk\third-party\${jmsedm-artifactId.new}
of C:\svn\trunk\third-party\pom.xml does not exist
I've never used variables for module names before so I don't know if this
is a regression or if it's intended to prevent this going forward, but it
used to work fine.
Regards,
-Dave
On Mon, Aug 15, 2016 at 4:24 AM, Samuel Langlois <
samuel.langlois@alfresco.com> wrote:
> On 13/08/2016 01:47, Christian Schulte wrote:
> > Am 08/12/16 um 15:58 schrieb Samuel Langlois:
> > > Thanks for your answer Robert.
> > > It is a bit more complicated than just being unable to override a
> > property.
> > > It's more that you can't change a dependencyManagement defined above by
> > > overriding a property.
> > > Anyway, I think it deserves an issue to be looked at properly, so I
> > created
> > > https://issues.apache.org/jira/browse/MNG-6079
> >
> > That issue has been fixed. You can test the fix using a recent
> > 3.4.0-SNAPSHOT available from here:
> > <https://builds.apache.org/job/maven-3.3-release-status-build/>.
>
> Indeed, the previous behaviour is now restored. And my build passes fine
> :-)
> Thanks a lot for your support
> --
> Samuel Langlois
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.
> com/Preleminary-Maven-3-4-0-SNAPSHOT-Testing-Take-3-tp5874456p5877978.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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 Samuel Langlois <sa...@alfresco.com>.
On 13/08/2016 01:47, Christian Schulte wrote:
> Am 08/12/16 um 15:58 schrieb Samuel Langlois:
> > Thanks for your answer Robert.
> > It is a bit more complicated than just being unable to override a
> property.
> > It's more that you can't change a dependencyManagement defined above by
> > overriding a property.
> > Anyway, I think it deserves an issue to be looked at properly, so I
> created
> > https://issues.apache.org/jira/browse/MNG-6079
>
> That issue has been fixed. You can test the fix using a recent
> 3.4.0-SNAPSHOT available from here:
> <https://builds.apache.org/job/maven-3.3-release-status-build/>.
Indeed, the previous behaviour is now restored. And my build passes fine :-)
Thanks a lot for your support
--
Samuel Langlois
--
View this message in context: http://maven.40175.n5.nabble.com/Preleminary-Maven-3-4-0-SNAPSHOT-Testing-Take-3-tp5874456p5877978.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
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/12/16 um 15:58 schrieb Samuel Langlois:
> Thanks for your answer Robert.
> It is a bit more complicated than just being unable to override a property.
> It's more that you can't change a dependencyManagement defined above by
> overriding a property.
> Anyway, I think it deserves an issue to be looked at properly, so I created
> https://issues.apache.org/jira/browse/MNG-6079
That issue has been fixed. You can test the fix using a recent
3.4.0-SNAPSHOT available from here:
<https://builds.apache.org/job/maven-3.3-release-status-build/>.
See this commit
<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=814b5166123c54b21545038038536063ce8dba1c>.
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 Samuel Langlois <sa...@alfresco.com>.
Thanks for your answer Robert.
It is a bit more complicated than just being unable to override a property.
It's more that you can't change a dependencyManagement defined above by
overriding a property.
Anyway, I think it deserves an issue to be looked at properly, so I created
https://issues.apache.org/jira/browse/MNG-6079
Thanks
--
View this message in context: http://maven.40175.n5.nabble.com/Preleminary-Maven-3-4-0-SNAPSHOT-Testing-Take-3-tp5874456p5877664.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
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 Robert Patrick <ro...@oracle.com>.
This should be treated as a bug. Many builds, including ours, relies on being able to override properties defined in the parent hierarchy in a module POM. This change you are describing would break a lot of builds...
> On Aug 12, 2016, at 8:41 AM, Samuel Langlois <sa...@alfresco.com> wrote:
>
> Hello
>
> I noticed a change of behaviour in Maven 3.4, which made one of our builds
> fail.
> It may be a bit of a corner case, so I'll let someone else decide whether
> it's a regression or a bug fix...
>
> We have a submodule where the "parent" pom contains a dependency with
> scope=import, but with the version set using a property:
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.alfresco</groupId>
> <artifactId>alfresco-platform-distribution</artifactId>
> <version>${alfresco.version}</version>
> <type>pom</type>
> <scope>import</scope>
> </dependency>
>
> In the submodule itself, we override this version to be a more recent one:
> <properties>
> <alfresco.version>5.1.e</alfresco.version>
> </properties>
>
> In Maven 3.3 and before, the override is working, and we inherit version
> 5.1.e of the dependencies.
> In maven 3.4, it doesn't any more, so we get older versions of the
> dependencies.
>
> It works fine if I move the property override to the parent pom, i.e. the
> one where the import dependency is defined.
> I've just retested using the latest 3.4.0-SNAPSHOT from 2016-08-06
>
> Thanks for your insight
> --
> Samuel
>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Preleminary-Maven-3-4-0-SNAPSHOT-Testing-Take-3-tp5874456p5877660.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org