Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

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.



> 
> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[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'.

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 @@
net.imagej.Main
+   2.0.0-rc-49


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  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:
> 
>
> 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-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

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:


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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stephane Nicoll]

On Thu, Aug 18, 2016 at 5:24 PM, Curtis Rueden  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.nic...@gmail.com>
> wrote:
>
> > On Tue, Aug 16, 2016 at 11:14 PM, Curtis Rueden 
> 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 (typica

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[jieryn]

Sorry I am so late to this party.

I find that Apache Maven 3.4.0-SNAPSHOT
(90f26c279af9738735be8f84f60dcf21b6244e24; 2016-07-22T11:23:04-04:00)
prefers .mvn/maven.config options instead of specifically listed
parameters. This is surprising to me. I expect the .mvn/maven.config
options to be overriden by any actual parameters that I specify on the
command line.

Specifically, I am trying to override the maven.config --fail-at-end
via --fail-fast, and also --threads 2.0C with --threads 1. When I
invoke mvn, it seems the maven.config options are taken instead of my
local cli invocation. These have a bad effect on my invocation and
cause a lot of trouble. We do not check in our .mvn/maven.config, so I
can not simply rm -rf it and then check it out after... it's a pita,
and bad karma. Please examine it :) thank you.

On Fri, Jul 22, 2016 at 11:27 AM, Karl Heinz Marbaise  wrote:
> Hi to all Maven users,
>
> If you like to help making the next Maven release better it would be nice if
> you could help a little bit.
>
> Please be aware of this *** This is not an official release ***
>
> I have created downloadable packages which are available from here:
>
>
> Windows: https://s.apache.org/vG4r
> Linux/Mac: https://s.apache.org/FfRw
>
> Every kind of feedback is helpful.
>
> Important hint:
>
> This is only a current state of development (Git hash:
> 90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
> community...
>
> The current list of changes can be seen in the issue tracker:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.4.0
>
> It would be nice if those who had found issues to retest their scenarios.
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Curtis Rueden]

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 
wrote:

> On Tue, Aug 16, 2016 at 11:14 PM, Curtis Rueden  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: 

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stephane Nicoll]

On Tue, Aug 16, 2016 at 11:14 PM, Curtis Rueden  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  section of the project POM has no effect on
> the final resol

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stephane Nicoll]

On Wed, Aug 17, 2016 at 10:16 PM, Curtis Rueden  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  wrote:
>
> > Am 08/17/16 um 04:09 schrieb Mark Derricutt:
> > > On 17 Aug 2016, at 12:32, Christian Schulte wrote:
> > >
> > >> There is an easy way to solve this. Maven validates the model version
> in
> > >> the POM to match "4.0.0". Based on that version, Maven can decide how
> to
> > >> behave. I am thinking about introducing model version "4.1.0" in Maven
> > >> 3.4. All existing 4.0.0 POMs will work the same way as before. Model
> > >
> > > Would the deployed POM be a 4.1.0 or 4.0.0 Model? I seem to recall a
> > long time ago when we were doing the Google Hangouts discussions about a
> > mental separation of build/deploy POM.
> >
> > Deployed as 4.1.0. Yes, that means POMs will start to appear not useable
> > with Maven < 3.4. Tools parsing the POMs themselves (not using
> > maven-model-builder) would need to support that as well.
> >
> > >
> > > If deployed as 4.1.0 then you'd be forcing all consumers of that
> > dependency to use Maven 3.4.0 itself ( IMHO not in itself a bad idea ),
> but
> > that might hurt any consuming applications like Sonar, Jenkins, or other
> > build tools.
> > >
> >
> > That's the drawback I am seeing as well. It's the same syntax with
> > different semantics. That's why Maven < 3.4 would need to abort.
> > Everything < 3.4 cannot provide the behaviour for that model version and
> > thus must not e.g. silently ignore XML elements leading to e.g.
> > different dependency trees when used with >= 3.4. It's a question of how
> > to progress Maven core when it comes to changes in behaviour making
> > sense. "Has always been that way -> must not change." Means we can never
> > change anything and must provide new features for changing things (e.g.
> > keep the import scope the way it always has been and introduce an
> > include scope with the new behaviour and document the import scope is
> > considered deprecated). It's not always possible to introduce a change
> > as a new feature. We recently discussed the addition of some kind of
> > feature toggles or knobs. That won't work, in my opinion, because Maven
> > would behave differently based on command line options. It's not
> > possible to deploy a POM to central whose correct/intended behaviour
> > depends on a specical command line option in use. I see no other way to
> > incrementing the model version for such things. Maven needs to know how
> > to behave solely based on what is in the POM. Nothing syntax related.
> >
> > Regards,
> > --
> > Christian
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Curtis Rueden]

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  wrote:

> Am 08/17/16 um 04:09 schrieb Mark Derricutt:
> > On 17 Aug 2016, at 12:32, Christian Schulte wrote:
> >
> >> There is an easy way to solve this. Maven validates the model version in
> >> the POM to match "4.0.0". Based on that version, Maven can decide how to
> >> behave. I am thinking about introducing model version "4.1.0" in Maven
> >> 3.4. All existing 4.0.0 POMs will work the same way as before. Model
> >
> > Would the deployed POM be a 4.1.0 or 4.0.0 Model? I seem to recall a
> long time ago when we were doing the Google Hangouts discussions about a
> mental separation of build/deploy POM.
>
> Deployed as 4.1.0. Yes, that means POMs will start to appear not useable
> with Maven < 3.4. Tools parsing the POMs themselves (not using
> maven-model-builder) would need to support that as well.
>
> >
> > If deployed as 4.1.0 then you'd be forcing all consumers of that
> dependency to use Maven 3.4.0 itself ( IMHO not in itself a bad idea ), but
> that might hurt any consuming applications like Sonar, Jenkins, or other
> build tools.
> >
>
> That's the drawback I am seeing as well. It's the same syntax with
> different semantics. That's why Maven < 3.4 would need to abort.
> Everything < 3.4 cannot provide the behaviour for that model version and
> thus must not e.g. silently ignore XML elements leading to e.g.
> different dependency trees when used with >= 3.4. It's a question of how
> to progress Maven core when it comes to changes in behaviour making
> sense. "Has always been that way -> must not change." Means we can never
> change anything and must provide new features for changing things (e.g.
> keep the import scope the way it always has been and introduce an
> include scope with the new behaviour and document the import scope is
> considered deprecated). It's not always possible to introduce a change
> as a new feature. We recently discussed the addition of some kind of
> feature toggles or knobs. That won't work, in my opinion, because Maven
> would behave differently based on command line options. It's not
> possible to deploy a POM to central whose correct/intended behaviour
> depends on a specical command line option in use. I see no other way to
> incrementing the model version for such things. Maven needs to know how
> to behave solely based on what is in the POM. Nothing syntax related.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stephane Nicoll]

On Tue, Aug 16, 2016 at 11:14 PM, Curtis Rueden  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  sec

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

Am 08/17/16 um 04:09 schrieb Mark Derricutt:
> On 17 Aug 2016, at 12:32, Christian Schulte wrote:
> 
>> There is an easy way to solve this. Maven validates the model version in
>> the POM to match "4.0.0". Based on that version, Maven can decide how to
>> behave. I am thinking about introducing model version "4.1.0" in Maven
>> 3.4. All existing 4.0.0 POMs will work the same way as before. Model
> 
> Would the deployed POM be a 4.1.0 or 4.0.0 Model? I seem to recall a long 
> time ago when we were doing the Google Hangouts discussions about a mental 
> separation of build/deploy POM.

Deployed as 4.1.0. Yes, that means POMs will start to appear not useable
with Maven < 3.4. Tools parsing the POMs themselves (not using
maven-model-builder) would need to support that as well.

> 
> If deployed as 4.1.0 then you'd be forcing all consumers of that dependency 
> to use Maven 3.4.0 itself ( IMHO not in itself a bad idea ), but that might 
> hurt any consuming applications like Sonar, Jenkins, or other build tools.
> 

That's the drawback I am seeing as well. It's the same syntax with
different semantics. That's why Maven < 3.4 would need to abort.
Everything < 3.4 cannot provide the behaviour for that model version and
thus must not e.g. silently ignore XML elements leading to e.g.
different dependency trees when used with >= 3.4. It's a question of how
to progress Maven core when it comes to changes in behaviour making
sense. "Has always been that way -> must not change." Means we can never
change anything and must provide new features for changing things (e.g.
keep the import scope the way it always has been and introduce an
include scope with the new behaviour and document the import scope is
considered deprecated). It's not always possible to introduce a change
as a new feature. We recently discussed the addition of some kind of
feature toggles or knobs. That won't work, in my opinion, because Maven
would behave differently based on command line options. It's not
possible to deploy a POM to central whose correct/intended behaviour
depends on a specical command line option in use. I see no other way to
incrementing the model version for such things. Maven needs to know how
to behave solely based on what is in the POM. Nothing syntax related.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[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.

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


signature.asc
Description: OpenPGP digital signature

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Curtis Rueden]

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  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 thr

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stephane Nicoll]

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  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" 
> wrote:
>
> > On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte 
> 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-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Curtis Rueden]

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  wrote:

> Could you please test properties can correctly be overridden again in
> the latest 3.4.0-SNAPSHOT available from
> . It
> should have been fixed by this commit
>  814b5166123c54b21545038038536063ce8dba1c>.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Curtis Rueden]

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" 
wrote:

> On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte  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-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Stephane Nicoll]

On Sat, Aug 13, 2016 at 12:49 AM, Christian Schulte  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-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[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.

Regards,
-Dave

On Mon, Aug 15, 2016 at 12:40 PM, Christian Schulte  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.
> >
> > 
> > exchange
> > asw
> > third-party-jax-ws-model
> > ${jmsedm-artifactId.new}
> > third-party-enterprise-messaging
> > third-party-ccsds
> > 
> >
> > In the parent pom we have that property defined as:
> >
> > 3.3.0
> > jmsedm-v${jmsedm.version}
> >
> > 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-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

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.
> 
> 
> exchange
> asw
> third-party-jax-ws-model
> ${jmsedm-artifactId.new}
> third-party-enterprise-messaging
> third-party-ccsds
> 
> 
> In the parent pom we have that property defined as:
> 
> 3.3.0
> jmsedm-v${jmsedm.version}
> 
> 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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[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.


exchange
asw
third-party-jax-ws-model
${jmsedm-artifactId.new}
third-party-enterprise-messaging
third-party-ccsds


In the parent pom we have that property defined as:

3.3.0
jmsedm-v${jmsedm.version}

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.langl...@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:
> > .
>
> 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-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Samuel Langlois]

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:
> .

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

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:
.

See this commit
.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

Could you please test properties can correctly be overridden again in
the latest 3.4.0-SNAPSHOT available from
. It
should have been fixed by this commit
.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

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.





Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

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:
> 
> 
> maven-jar-plugin
> 3.0.2
> 
> 
> 
> 
> ${scijava-common.version}
> 
> 
> 
> 
> 
> 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:


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 uns

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[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.

> > 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:


maven-jar-plugin
3.0.2




${scijava-common.version}





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  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:
>>
>> 
>> ca.mcgill
>> Sholl_Analysis
>> runtime
>> 
>>
>> 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
>>
>> 
>> 
>> 3.6.2
>>  ...
>> 
>> 
>> 
>>  ca.mcgill
>> Sholl_Analysis
>> ${Sholl_Analysis.version} 
>> 
>> 
>>
>> 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
>>
>> 
>> 
>> 
>> 
>> sc.fiji
>> pom-bigdataviewer
>> ${pom-bigdataviewer.version}
>> pom
>> import
>> 
>> 
>> 
>> sc.fiji
>> pom-trakem2
>> ${pom-trakem2.version}
>> pom
>> import
>> 
>> 
>> 
>>
>> 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 manageme

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

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:


ca.mcgill
Sholl_Analysis
runtime


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



3.6.2
 ...



 ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version} 



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





sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import



sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import




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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[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:


ca.mcgill
Sholl_Analysis
runtime


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



3.6.2
 ...



 ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version} 



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





sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import



sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import




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  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:
>
> 
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

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:



Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[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

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Robert Patrick]

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  
> 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:
>   
>  
> 
>org.alfresco
>alfresco-platform-distribution
>${alfresco.version}
>pom
>import
> 
> 
> In the submodule itself, we override this version to be a more recent one:
>   
>  5.1.e
>   
> 
> 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-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[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...

We have a submodule where the "parent" pom contains a dependency with
scope=import, but with the version set using a property:
   
  
 
org.alfresco
alfresco-platform-distribution
${alfresco.version}
pom
import
 

In the submodule itself, we override this version to be a more recent one:
   
  5.1.e
   

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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Dan Tran]

Spring folks agree it is a bug. See StackOverflow link for details

-Dan

On Sun, Jul 24, 2016 at 11:11 AM, Dan Tran  wrote:

>
> http://stackoverflow.com/questions/38555184/json-simple-marked-as-optional-under-spring-boot-dependencies-intentional
>
> For my case, i override it at my BOM
>
> -D
>
> On Sun, Jul 24, 2016 at 10:44 AM, Christian Schulte  wrote:
>
>> Am 07/24/16 um 19:25 schrieb Dan Tran:
>> > Yes, I need to override the original import with  'optional' set to
>> false.
>> > At the same time, i file a bug  with spring to see if it is intentional
>> >
>>
>> This is what I would do as well. If the majority of users will never
>> need that dependency and it is not needed for normal operation, optional
>> is the way to go. If the majority will need to override this to false,
>> they should remove optional from the BOM. I've seen optional set to true
>> for runtime scope dependencies most of the time. The way it is used in
>> that BOM, they could also use provided scope (compile+optional behaves
>> the same way the provided scope behaves).
>>
>> Regards,
>> --
>> Christian
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Mirko Friedenhagen]

Hello,

I just published a Docker image at
https://hub.docker.com/r/mfriedenhagen/docker-maven/. However, because
I often use Maven in a CI environment I replaced the gossip and jansi
jars with slf4j-simple.
After adapting findbugs-maven-plugin to 3.0.4 my projects run successfully.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Sat, Jul 23, 2016 at 11:41 PM, Dan Tran  wrote:
> Looks good on my 170 modules with Takari's  smart builder build.  Except
> one module with one transitive dependency disappears and causes compilation
> error.
>
> Any suggestion how to troubleshoot is very much reproducible build failure?
>
> Thanks
>
> -Dan
>
>
>
> On Fri, Jul 22, 2016 at 3:14 PM, Mark Derricutt  wrote:
>
>> On Sat, Jul 23, 2016 at 3:27 AM, Karl Heinz Marbaise 
>> wrote:
>>
>> > This is only a current state of development (Git hash:
>> > 90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
>> > community...
>> >
>>
>> Have been using daily HEAD builds as my daily driver for the past few
>> weeks, so far no issues on any of our projects, so here's my pre-emptive +2
>> :)
>>
>> --
>> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
>> Porcupine Tree
>>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Dan Tran]

http://stackoverflow.com/questions/38555184/json-simple-marked-as-optional-under-spring-boot-dependencies-intentional

For my case, i override it at my BOM

-D

On Sun, Jul 24, 2016 at 10:44 AM, Christian Schulte  wrote:

> Am 07/24/16 um 19:25 schrieb Dan Tran:
> > Yes, I need to override the original import with  'optional' set to
> false.
> > At the same time, i file a bug  with spring to see if it is intentional
> >
>
> This is what I would do as well. If the majority of users will never
> need that dependency and it is not needed for normal operation, optional
> is the way to go. If the majority will need to override this to false,
> they should remove optional from the BOM. I've seen optional set to true
> for runtime scope dependencies most of the time. The way it is used in
> that BOM, they could also use provided scope (compile+optional behaves
> the same way the provided scope behaves).
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

Am 07/24/16 um 19:25 schrieb Dan Tran:
> Yes, I need to override the original import with  'optional' set to false.
> At the same time, i file a bug  with spring to see if it is intentional
> 

This is what I would do as well. If the majority of users will never
need that dependency and it is not needed for normal operation, optional
is the way to go. If the majority will need to override this to false,
they should remove optional from the BOM. I've seen optional set to true
for runtime scope dependencies most of the time. The way it is used in
that BOM, they could also use provided scope (compile+optional behaves
the same way the provided scope behaves).

Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Dan Tran]

Yes, I need to override the original import with  'optional' set to false.
At the same time, i file a bug  with spring to see if it is intentional

Thanks

-D



On Sun, Jul 24, 2016 at 9:54 AM, Christian Schulte  wrote:

> Am 07/24/16 um 09:32 schrieb Dan Tran:
> > yes, found this
> >
> > 
> > com.googlecode.json-simple
> > json-simple
> > ${simple-json.version}
> > true
> > 
> >
> > at sprint-boot-dependencies-1.2.8's dependencyManagement.  This may be a
> > bug of the BOM.  Not sure why it is set as optional and it is the only
> one
> > in that BOM.
>
> This must have been done intentionally without the author noticing this
> is not working. What to do about it depends on you needing that
> dependency or not. Maybe ask upstream what they recommend you to do
> about it. It's optional for a reason. If you are importing that BOM and
> decide you need that dependency, you need to set optional to false
> manually where the dependency is used to override the imported
> management information.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

Am 07/24/16 um 09:32 schrieb Dan Tran:
> yes, found this
> 
> 
> com.googlecode.json-simple
> json-simple
> ${simple-json.version}
> true
> 
> 
> at sprint-boot-dependencies-1.2.8's dependencyManagement.  This may be a
> bug of the BOM.  Not sure why it is set as optional and it is the only one
> in that BOM.

This must have been done intentionally without the author noticing this
is not working. What to do about it depends on you needing that
dependency or not. Maybe ask upstream what they recommend you to do
about it. It's optional for a reason. If you are importing that BOM and
decide you need that dependency, you need to set optional to false
manually where the dependency is used to override the imported
management information.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Dan Tran]

http://central.maven.org/maven2/org/springframework/boot/spring-boot-dependencies/1.3.6.RELEASE/spring-boot-dependencies-1.3.6.RELEASE.pom




On Sun, Jul 24, 2016 at 12:32 AM, Dan Tran  wrote:

> yes, found this
>
> 
> com.googlecode.json-simple
> json-simple
> ${simple-json.version}
> true
> 
>
> at sprint-boot-dependencies-1.2.8's dependencyManagement.  This may be a
> bug of the BOM.  Not sure why it is set as optional and it is the only one
> in that BOM.
>
> Thanks
>
> -D
>
> On Sat, Jul 23, 2016 at 4:12 PM, Christian Schulte  wrote:
>
>> Am 07/23/16 um 23:41 schrieb Dan Tran:
>> > Looks good on my 170 modules with Takari's  smart builder build.  Except
>> > one module with one transitive dependency disappears and causes
>> compilation
>> > error.
>> >
>> > Any suggestion how to troubleshoot is very much reproducible build
>> failure?
>>
>> Could be caused by having set 'optional' to 'true' of that dependency
>> somewhere. If that's the case, then it's correct that the dependency
>> disappears. Bug is the dependency beeing part of the classpath although
>> optional is set to true.
>>
>> Regards,
>> --
>> Christian
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Dan Tran]

yes, found this


com.googlecode.json-simple
json-simple
${simple-json.version}
true


at sprint-boot-dependencies-1.2.8's dependencyManagement.  This may be a
bug of the BOM.  Not sure why it is set as optional and it is the only one
in that BOM.

Thanks

-D

On Sat, Jul 23, 2016 at 4:12 PM, Christian Schulte  wrote:

> Am 07/23/16 um 23:41 schrieb Dan Tran:
> > Looks good on my 170 modules with Takari's  smart builder build.  Except
> > one module with one transitive dependency disappears and causes
> compilation
> > error.
> >
> > Any suggestion how to troubleshoot is very much reproducible build
> failure?
>
> Could be caused by having set 'optional' to 'true' of that dependency
> somewhere. If that's the case, then it's correct that the dependency
> disappears. Bug is the dependency beeing part of the classpath although
> optional is set to true.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Christian Schulte]

Am 07/23/16 um 23:41 schrieb Dan Tran:
> Looks good on my 170 modules with Takari's  smart builder build.  Except
> one module with one transitive dependency disappears and causes compilation
> error.
> 
> Any suggestion how to troubleshoot is very much reproducible build failure?

Could be caused by having set 'optional' to 'true' of that dependency
somewhere. If that's the case, then it's correct that the dependency
disappears. Bug is the dependency beeing part of the classpath although
optional is set to true.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Dan Tran]

Looks good on my 170 modules with Takari's  smart builder build.  Except
one module with one transitive dependency disappears and causes compilation
error.

Any suggestion how to troubleshoot is very much reproducible build failure?

Thanks

-Dan



On Fri, Jul 22, 2016 at 3:14 PM, Mark Derricutt  wrote:

> On Sat, Jul 23, 2016 at 3:27 AM, Karl Heinz Marbaise 
> wrote:
>
> > This is only a current state of development (Git hash:
> > 90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
> > community...
> >
>
> Have been using daily HEAD builds as my daily driver for the past few
> weeks, so far no issues on any of our projects, so here's my pre-emptive +2
> :)
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Mark Derricutt]

On Sat, Jul 23, 2016 at 3:27 AM, Karl Heinz Marbaise 
wrote:

> This is only a current state of development (Git hash:
> 90f26c279af9738735be8f84f60dcf21b6244e24) to get some feedback from the
> community...
>

Have been using daily HEAD builds as my daily driver for the past few
weeks, so far no issues on any of our projects, so here's my pre-emptive +2
:)

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

[Andreas Sewe]

Hi,

> If you like to help making the next Maven release better it would be
> nice if you could help a little bit.
> 
> Please be aware of this *** This is not an official release ***
> 
> Every kind of feedback is helpful.

the good needs is that I found no regressions (testing several large
builds at eclipse.org using Maven + Tycho).

The bad news is that the child.inherit.append.path attribute introduced
with MNG-5951 is not flexible enough for fairy common use cases like
projects on Github. I opened bug MNG-6059 [1] for this.

Hope that helps.

Andreas

[1] 

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org