[MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Hi,

starting to write up some documentation for 3.4.0 has lead to (re-)
reading various parts of the existing documentation. Regarding the issue
in the subject. Would it be ok to include the corresponding fix in
3.4.0? It makes Maven 3.4.0 dependency management behave exactly as it
is documented. Currently dependency management really is not transitive
and is still kept compatible to Maven 2 (broken behaviour). Fix would be
to replace ClassicDependencyManager [1] with TransitiveDependencyManaget
[1]. This is one of things postponed a few months ago when the maven
resolver was on its way. Now that it's there, I see no reason to not
include that fix in 3.4.0. Why keep things still compatible to Maven 2
when that is EOL? WDYT?

[1]
<https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=tree;f=maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager;h=79506b8e925b5586c8065204997ead06245686bf;hb=HEAD>

Regards,
-- 
Christian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Stephen Connolly <st...@gmail.com>]

On 17 November 2016 at 14:36, Jason van Zyl <ja...@takari.io> wrote:

> Hyperbole easily made fact so let’s ask and then there will be no
> question. I have thousands of users in my organization, Igor likely has
> something similar. We don’t work together on a daily basis anymore but
> small changes have a dire impact and both of us care greatly about the
> preservation and consistency of behavior because it matters greatly in
> terms of usability, user trust in the systems we build, and real support
> costs. We also care about this on a large scale where these concerns are
> magnified intensely for all Maven users. It is a very well educated guess
> based on past experience that changes made like this reflect isolated
> development. Christian can clarify how many users he’s responsible for as
> I’m absolutely certain he’s not running a support organization. These
> concerns have always influenced my behavior, Igor is similar and I make
> zero apologies because it will impact my users, and will reflect poorly on
> the project globally and immediately. I will “trample” as much as necessary
> to preserve behavior for users. Igor and I have made fairly radical changes
> while preserving all existing behavior for existing users, we’ve outline
> how we did it: separate implementations, user opt-in, over time it may
> become default behavior if so desired by users.
>
> Stephen, have you looked at the history for the core and the integration
> tests? What do you see? Tell me how much consensus we had for all those
> changes.
>
> ITs are broken in a fundamental way, no release notes in SVN, no notes
> anywhere I can see that would explain how the changes would impact a user
> or what they do to understand. This is how you go pretty far to losing your
> community. Our users are normal everyday developers, they just want things
> to work, all systems have quirks and many have just lived with the scar
> tissue, software gets delivered, compromises get made, people go home at
> the end of the day. For the succession of minor releases everything needs
> to work, we live with our baggage. This, to me what we have right now is a
> potential flaming train wreck waiting to happen. I’m not really concerned
> with one person who seems not to understand this. My concern is about
> destroying the trust we’ve built up over the years in one fell swoop.
>

I am not happy with the current state of the integration tests

I am not happy that there have been changes that break backwards
compatibility in an unconsidered fashion.

But I do think we can make considered changes that break backwards
compatibility in known and defined concrete ways.

I will direct your attention to the change in the 3.3.x line where the in
memory model was made read-only.

This affects any multi-module Maven build where the shade plugin is used to
replace the primary artifact with one where it has shades some - but not
all - of the dependencies of an artifact and then that shaded artifact is
consumed by another module in the reactor (especially where that module is
not a jar file but rather something that aggregates jars, e.g. a war or an
ear)

In that case you will end up with a multi-module build where the .war
includes the shaded jar and *all* its *original* dependencies.

If you instead build the reactor one module at a time using `install` then
the .war will only include the non-shaded dependencies of the jar.

Now none of this happens with 2.0-3.2.x

It is a small regression in one sense... and you can fix it with some scope
(or <optional>true</optional>) changes (and those scope changes are
arguably the way shading in that use case should have been done
originally)... but this is still a regression and breaks existing builds in
a subtle way (one that took me quite some time to uncover)

That regression was driven by you IIRC, yet I do not see you clamouring to
revert the change and restore builds for your customers...

Now there are a number of questions/points that arise from the above
example:

1. Should we revert the change? If the principle is that we do not ship
breaking changes then we should revert the change and make the model
mutable... On the other hand I think that the impact is small (but deadly)
and the benefits of an immutable memory model are significant

2. The debate on making the memory model immutable did not expose this
regression. We can never ensure that we have a perfect debate on any
change. Making a new release always comes with the risk of breaking
something for somebody. If we could actually get into the habit of making
regular releases then this would not be as big a deal

While it is important that we maintain our community of users, doing that
requires that we maintain our community of developers. We should be
encouraging developers who do not have the weight of experience of having
many many customers to support to learn from us and to develop ways of
making changes that reduce risk.

FTR I am also concerned about some of the changes that seem to have gone in
for 3.4.0 (in fact I was the one who flagged the issue with the
modelVersion change) but I see that there is the potential that for some of
those changes the correct fix is to fix the integration tests... but they
need a case by case evaluation and I have not had the time to do that...
though on a release VOTE thread I will be reviewing the changes to the
integration tests as well as master

-Stephen


>
> > On Nov 17, 2016, at 12:10 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
> >
> > Jason, your hyperbole has slipped again. There is no need to make
> > assertions about how many or what kind of users other developers have
> > worked with, as that both does not foster the community and deflects from
> > the valid point you were otherwise making. Christian has done the right
> > thing in seeking consensus before attempting to make a change in this
> area
> > and what thanks does he get? Instead he gets trampled on because in the
> > past he made breaking changes that would have had grave consequences. Do
> > not trample on somebody for doing the wrong thing in the past when they
> are
> > in the middle of doing the right thing! Jason, as to breaking changes in
> a
> > minor version... does that mean we can revert the immutable model changes
> > that broke lots of shade users builds?
> >
> > Christian, this project has historically taken very seriously the goal of
> > allowing users to upgrade Maven without breaking their existing builds.
> > Whether we should continue to do so is a separate question, but certainly
> > we cannot change mid-major version.
> >
> > I am still working on my proposal for a version 5 of Maven. I am
> proposing
> > version 5 for two reasons:
> >
> > 1. It allows us to align the modelVersion with the Maven version
> > 2. It gives space for behavioural changes before the big pom format
> change
> >
> > Now having said that, my proposal for Maven 5 is just *my* proposal. From
> > the point of view of making a decision for the direction of this project
> my
> > voice is just one voice amongst all the *committers*. It is the
> > *committers* that decide the direction of this project - not the PMC. The
> > PMC is responsible for governance and ensuring that releases meet the
> > foundation's legal criteria established by the board.
> >
> > I am encouraged by the energy Christian is showing for this project, in
> > part it has inspired me to put effort into describing my plan for a way
> > forward.
> >
> > What we need to do right now is get 3.4.0 released. That means ensuring
> > that the integration tests pass. In a separate part of this thread Igor
> > reports that there are 24 tests not passing against master. Somebody
> needs
> > to diagnose why those tests are failing. Some failures may require
> changes
> > to the integration tests... some may require fixing the code. Let's
> figure
> > out what the story is for those 24 tests.
> >
> > The point we need to remember about the goal for 3.4.0 is to be a release
> > with the code formerly known as Aether moved to the Maven project and bug
> > fixes applied to that code. We should keep our focus on that and try not
> to
> > grow the scope... there are users clamouring for fixing that set of
> > problems.
> >
> > Once we have the 3.4.x line then we should sit down and plan the path
> > forward.
> >
> > -Stephen
> >
> >
> > On 16 November 2016 at 05:44, Christian Schulte <cs...@schulte.it> wrote:
> >
> >> To sum it up. I've asked the very same question a few weeks ago. That
> >> has lead to creating that maven-3.x-next branch. A few weeks later I get
> >> a different answer and that branch becomes obsolete and all JIRA issues
> >> for version 3.5.0 need updating and the branch can be deleted, because
> >> it became meaningless.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [MNG-5761] Dependency management is not transitive.

[Jason van Zyl <ja...@takari.io>]

Hyperbole easily made fact so let’s ask and then there will be no question. I have thousands of users in my organization, Igor likely has something similar. We don’t work together on a daily basis anymore but small changes have a dire impact and both of us care greatly about the preservation and consistency of behavior because it matters greatly in terms of usability, user trust in the systems we build, and real support costs. We also care about this on a large scale where these concerns are magnified intensely for all Maven users. It is a very well educated guess based on past experience that changes made like this reflect isolated development. Christian can clarify how many users he’s responsible for as I’m absolutely certain he’s not running a support organization. These concerns have always influenced my behavior, Igor is similar and I make zero apologies because it will impact my users, and will reflect poorly on the project globally and immediately. I will “trample” as much as necessary to preserve behavior for users. Igor and I have made fairly radical changes while preserving all existing behavior for existing users, we’ve outline how we did it: separate implementations, user opt-in, over time it may become default behavior if so desired by users. 

Stephen, have you looked at the history for the core and the integration tests? What do you see? Tell me how much consensus we had for all those changes.

ITs are broken in a fundamental way, no release notes in SVN, no notes anywhere I can see that would explain how the changes would impact a user or what they do to understand. This is how you go pretty far to losing your community. Our users are normal everyday developers, they just want things to work, all systems have quirks and many have just lived with the scar tissue, software gets delivered, compromises get made, people go home at the end of the day. For the succession of minor releases everything needs to work, we live with our baggage. This, to me what we have right now is a potential flaming train wreck waiting to happen. I’m not really concerned with one person who seems not to understand this. My concern is about destroying the trust we’ve built up over the years in one fell swoop.


> On Nov 17, 2016, at 12:10 AM, Stephen Connolly <st...@gmail.com> wrote:
> 
> Jason, your hyperbole has slipped again. There is no need to make
> assertions about how many or what kind of users other developers have
> worked with, as that both does not foster the community and deflects from
> the valid point you were otherwise making. Christian has done the right
> thing in seeking consensus before attempting to make a change in this area
> and what thanks does he get? Instead he gets trampled on because in the
> past he made breaking changes that would have had grave consequences. Do
> not trample on somebody for doing the wrong thing in the past when they are
> in the middle of doing the right thing! Jason, as to breaking changes in a
> minor version... does that mean we can revert the immutable model changes
> that broke lots of shade users builds?
> 
> Christian, this project has historically taken very seriously the goal of
> allowing users to upgrade Maven without breaking their existing builds.
> Whether we should continue to do so is a separate question, but certainly
> we cannot change mid-major version.
> 
> I am still working on my proposal for a version 5 of Maven. I am proposing
> version 5 for two reasons:
> 
> 1. It allows us to align the modelVersion with the Maven version
> 2. It gives space for behavioural changes before the big pom format change
> 
> Now having said that, my proposal for Maven 5 is just *my* proposal. From
> the point of view of making a decision for the direction of this project my
> voice is just one voice amongst all the *committers*. It is the
> *committers* that decide the direction of this project - not the PMC. The
> PMC is responsible for governance and ensuring that releases meet the
> foundation's legal criteria established by the board.
> 
> I am encouraged by the energy Christian is showing for this project, in
> part it has inspired me to put effort into describing my plan for a way
> forward.
> 
> What we need to do right now is get 3.4.0 released. That means ensuring
> that the integration tests pass. In a separate part of this thread Igor
> reports that there are 24 tests not passing against master. Somebody needs
> to diagnose why those tests are failing. Some failures may require changes
> to the integration tests... some may require fixing the code. Let's figure
> out what the story is for those 24 tests.
> 
> The point we need to remember about the goal for 3.4.0 is to be a release
> with the code formerly known as Aether moved to the Maven project and bug
> fixes applied to that code. We should keep our focus on that and try not to
> grow the scope... there are users clamouring for fixing that set of
> problems.
> 
> Once we have the 3.4.x line then we should sit down and plan the path
> forward.
> 
> -Stephen
> 
> 
> On 16 November 2016 at 05:44, Christian Schulte <cs...@schulte.it> wrote:
> 
>> To sum it up. I've asked the very same question a few weeks ago. That
>> has lead to creating that maven-3.x-next branch. A few weeks later I get
>> a different answer and that branch becomes obsolete and all JIRA issues
>> for version 3.5.0 need updating and the branch can be deleted, because
>> it became meaningless.
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Stephen Connolly <st...@gmail.com>]

Jason, your hyperbole has slipped again. There is no need to make
assertions about how many or what kind of users other developers have
worked with, as that both does not foster the community and deflects from
the valid point you were otherwise making. Christian has done the right
thing in seeking consensus before attempting to make a change in this area
and what thanks does he get? Instead he gets trampled on because in the
past he made breaking changes that would have had grave consequences. Do
not trample on somebody for doing the wrong thing in the past when they are
in the middle of doing the right thing! Jason, as to breaking changes in a
minor version... does that mean we can revert the immutable model changes
that broke lots of shade users builds?

Christian, this project has historically taken very seriously the goal of
allowing users to upgrade Maven without breaking their existing builds.
Whether we should continue to do so is a separate question, but certainly
we cannot change mid-major version.

I am still working on my proposal for a version 5 of Maven. I am proposing
version 5 for two reasons:

1. It allows us to align the modelVersion with the Maven version
2. It gives space for behavioural changes before the big pom format change

Now having said that, my proposal for Maven 5 is just *my* proposal. From
the point of view of making a decision for the direction of this project my
voice is just one voice amongst all the *committers*. It is the
*committers* that decide the direction of this project - not the PMC. The
PMC is responsible for governance and ensuring that releases meet the
foundation's legal criteria established by the board.

I am encouraged by the energy Christian is showing for this project, in
part it has inspired me to put effort into describing my plan for a way
forward.

What we need to do right now is get 3.4.0 released. That means ensuring
that the integration tests pass. In a separate part of this thread Igor
reports that there are 24 tests not passing against master. Somebody needs
to diagnose why those tests are failing. Some failures may require changes
to the integration tests... some may require fixing the code. Let's figure
out what the story is for those 24 tests.

The point we need to remember about the goal for 3.4.0 is to be a release
with the code formerly known as Aether moved to the Maven project and bug
fixes applied to that code. We should keep our focus on that and try not to
grow the scope... there are users clamouring for fixing that set of
problems.

Once we have the 3.4.x line then we should sit down and plan the path
forward.

-Stephen


On 16 November 2016 at 05:44, Christian Schulte <cs...@schulte.it> wrote:

> To sum it up. I've asked the very same question a few weeks ago. That
> has lead to creating that maven-3.x-next branch. A few weeks later I get
> a different answer and that branch becomes obsolete and all JIRA issues
> for version 3.5.0 need updating and the branch can be deleted, because
> it became meaningless.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

To sum it up. I've asked the very same question a few weeks ago. That
has lead to creating that maven-3.x-next branch. A few weeks later I get
a different answer and that branch becomes obsolete and all JIRA issues
for version 3.5.0 need updating and the branch can be deleted, because
it became meaningless.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/16/16 um 00:42 schrieb Christian Schulte:
> tracked with. Can we please line up all of this with everyone and with
> whatever changes others have in mind.

By this I mean the following. If the import scope behaviour cannot be
changed to what was done for MNG-5971 in any Maven 3.x version and Maven
3+n>0.x will introduce a new model version supporting mixins, there is
no need to talk about anything import scope anymore. Model version 4.0.0
import scope will behave the way it does today forever. New model
version supports mixins so projects needing MNG-5971 need to upgrade to
the new model version. See what I mean?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/17/16 um 06:00 schrieb Igor Fedorenko:
> FWIW, I ran maven integration tests (commit 73a2b7) against current
> maven master and got this
> 
>> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0
> 
> Running the same test checkout with Maven 3.3.9
> 
>>  Tests run: 771, Failures: 0, Errors: 0, Skipped: 0
> 


MavenITmng3843PomInheritanceTest:
Expected to fail due to MNG-2478. Revert MNG-2478?

MavenITmng4600DependencyOptionalFlagManagementTest:
Expected to fail due to MNG-5227. Upper bound added by me and comment
added to constructor. See commit [1].

MavenIT0051ReleaseProfileTest:
No idea yet. Maybe you need to disable the coloured output to get the
tests parsing log messages going again.

I stop here and re-run without coloured console. I know you cannot run
the ITs from that commit with coloured log messages.

[1]
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=6d31bdd72116dc6cc8bfe6182321076b4b371558>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/17/16 um 06:00 schrieb Igor Fedorenko:
> FWIW, I ran maven integration tests (commit 73a2b7) against current
> maven master and got this
> 
>> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0
> 
> Running the same test checkout with Maven 3.3.9
> 
>>  Tests run: 771, Failures: 0, Errors: 0, Skipped: 0
> 

I just started the 'core-it-maven-3-win' job on Jenkins. That job at
least is running the ITs now. Let's see what this will lead to. Maybe
it's a windows only issue I could not notice due to the job in jenkins
not running. Let's see.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/17/16 um 21:43 schrieb Christian Schulte:
> Am 11/17/16 um 06:00 schrieb Igor Fedorenko:
>> FWIW, I ran maven integration tests (commit 73a2b7) against current
>> maven master and got this
>>
>>> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0
>>
>> Running the same test checkout with Maven 3.3.9
>>
>>>  Tests run: 771, Failures: 0, Errors: 0, Skipped: 0
>>
> 
> last time I started that job, the ITs ran successfully. I just started
> that job again, it has not caught up with recent commits so far. Let's
> see what will happen.

maven-3.3-release-status-test-linux

[INFO] BUILD SUCCESS

maven-3.3-release-status-test-windows

Does not even run the tests and fails right from the start setting up
the IT environment. I tried re-building that job but get


f:\ws\m33-rs>jar -xvf archive.zip
'jar' is not recognized as an internal or external command,
operable program or batch file.

and cannot run a single test.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/19/16 um 03:58 schrieb Igor Fedorenko:
> Thank you for the analysis of the IT failures, Christian. I have a few
> questions/observations, if you don't mind
> 
> MavenITmng2199ParentVersionRangeTest.testValidLocalParentVersionRange
> From what I can tell, module uses parent version=[1.0,2) which matches
> locally available parent version=1.1. Can you explain why this test is
> expected to fail? 

The local parent version range logic was lacking validation. This commit
<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=893efe3a9c49952d916b0eac66973581cd2702cd>
added the missing validation (DefaultModelBuilder) so that there is no
difference any more in "parent from repository" vs. "parent from disc".
The IT is failing with:

[ERROR] The build could not read 1 project -> [Help 1]
org.apache.maven.project.ProjectBuildingException: Some problems were
encountered while processing the POMs:
[FATAL] Version must be a constant @
org.apache.maven.its.mng2199:local-parent-module:[unknown-version],
/home/schulte/Sources/apache.org/maven-integration-testing/
core-it-suite/target/test-classes/mng-2199-parent-version-range/local-parent/module/pom.xml,
line 2, column 10

In that module, the version must be constant due to the version range in
use. That's how the test would fail if the parent would not be on disc
but would need to be resolved from a repository. That validation has
been missing only for local parent poms. See the commit message:


o Updated to make local and remote parent model resolution consistent.
  'MavenProject.getParentArtifact()' now returns the same artifact
  no matter where the parent has been read from and the 'ModelBuilder'
  will disallow empty versions and version expressions in local child
  modules when using parent version ranges the same way as is done
  for remote parent models.

What to note here is that parent version ranges could only be used in
Maven 3.2.2. They are broken since 3.2.3. The ITs were incorrect and did
not catch that. There has been just that one Maven version around with
working parent version ranges. They will start working again in 3.4.

> 
> MavenITmng4600DependencyOptionalFlagManagementTest/MNG-5227
> This seems rather major dependency resolution change for 3.4 release,
> but I do not have strong opinion about the change otherwise.

In my opinion Maven 3 behaviour has been correct. MNG-4600 has been
reported as a regression against Maven 3.0-beta-1. Maven 3 has been
changed solely for backwards compatibility to Maven 2 although it's a
bug in Maven 2.

> 
> MavenITmng3719PomExecutionOrderingTest
> Shows that Maven used to allow the same plugin used in multiple <plugin>
> elements. I am actually surprised this worked in 3.3.9, but I think this
> will be a real problem for project that rely on this behaviour.
> 
> For other MNG-6075 changes, again, this maybe little too big a change
> for 3.4, but I think it is okay if remote pom.xml still work. Can you
> confirm that Maven is still able to use "old" pom.xml file from remote
> repositories?

I repeat the description of MNG-6075 here:
Maven 3 has warned about various model related issues clearly stating
that not reacting to those warnings may break with a future Maven
version. Starting with Maven 3.4, the model validation level has been
increased to the next minor version so that such warnings will become
errors as of 3.4.

My personal opinion to this is: If there are still projects around
refusing to fix theire POMs although they get warnings since years, what
can we do about it? Doing it was planned for Maven 3.1 already but has
never been done. If not done in 3.1, 3.2 and 3.3, then let's do it in
3.4. It's no big deal reverting that, though.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/19/16 um 23:57 schrieb Christian Schulte:
> Am 11/19/16 um 13:35 schrieb Igor Fedorenko:
>> What is parent version range syntax that works with 3.4? Or you are
>> saying parent version ranges are not supported at all now?

To not confuse anyone. The parent version range feature is not about
some kind of automatic versioning or such. As soon as a version range is
used in a <parent>, the project version can no longer be inherited and
must not use properties because the value may come from the effective
parent used but must not change. This has been validated for parent poms
resolved from repositories (readParentExternally) ever since. It was
lacking (in addition to any kind of version validation) for parent poms
resolved from disc (readParentLocally). This is all fixed in 3.4.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Stephen Connolly <st...@gmail.com>]

Given all the bugs I found in parent version ranges, it would not surprise
me if it had previously been appearing to work as long as you have a full
reactor, but using -pl to slice and dice the reactor or building individual
modules by cd-ing into them

But anyway YMMV

On Sat 19 Nov 2016 at 23:12, Igor Fedorenko <ig...@ifedorenko.com> wrote:

> Let me rephrase my question. What IT shows how to use parent version
> ranges with Maven 3.4?
>
> We actually use parent version ranges quite extensively internally, so I
> am trying to assess the impact of 3.4 changes for our users.
>
> --
> Regards,
> Igor
>
> On Sat, Nov 19, 2016, at 05:57 PM, Christian Schulte wrote:
> > Am 11/19/16 um 13:35 schrieb Igor Fedorenko:
> > > What is parent version range syntax that works with 3.4? Or you are
> > > saying parent version ranges are not supported at all now?
> >
> > They got introduced in 3.2.2. This commit
> > <
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=6cf9320942c34bc68205425ab696b1712ace9ba4
> >
> > about 2 weeks after the release of 3.2.2 broke parent version ranges.
> > They have not been working from there on anymore in any Maven release.
> > This commit
> > <
> https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=a6aca2894ab5a2849190cb802052710204081bf5
> >
> > fixes the ITs so that they start detecting parent version ranges are not
> > working. In between there have been commits fixing local parent
> > resolution (readParentLocally).
> >
> > <
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=40d5087b6b134842e2b61a567dbb4bfbcfab7ae6
> >
> >
> > <
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=25f5143169d39075cee67d9f4d11649cce0fafa0
> >
> >
> > <
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=bd87258629db8e3fcc7aa04777afc16314c3cde0
> >
> >
> > When fixing the remote parent resolution (readParentExternally) for 3.4,
> > I noticed the local parent resolution (readParentLocally) is lacking
> > validation.
> >
> > Maven 3.4 will be the first version ever supporting parent version
> > ranges consistently for local and remote parents.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone

Re: [MNG-5761] Dependency management is not transitive.

[Igor Fedorenko <ig...@ifedorenko.com>]

You are right, I was using the old version of the test project. The
latest version does work with 3.4 and does make sense. Thank you for the
explanation. 

-- 
Regards,
Igor

On Sat, Nov 19, 2016, at 09:36 PM, Christian Schulte wrote:
> Am 11/20/16 um 03:28 schrieb Igor Fedorenko:
> > I am sorry, Christian, I must be missing something obvious. When I try
> > building the IT project you suggested as an expect of correct parent
> > version usage [1] I get the error below when using current 3.4 master.
> > Are you able to build the project successfully?
> 
> Sure you are running the ITs @HEAD? That's what Jenkins is running and
> nothing fails there. The error message is what you get with the unfixed
> IT and then is expected. When I say "local" vs. "remote" parent
> resolution behave exactly the same there is one liddle difference left.
> For local poms, there is no way to check the version range in use
> contains an upper bound due to a different API in use. For external
> poms, there is an additional check that the range does contain an upper
> bound.
> 
> Do you really have projects where the <version> in <parent> is using a
> version range and do inherit the project version from the parent? How
> could you ever deploy something like that to a repository? Asking
> because I'd like to understand why you could not notice that these
> projects are not working as expected.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/20/16 um 03:28 schrieb Igor Fedorenko:
> I am sorry, Christian, I must be missing something obvious. When I try
> building the IT project you suggested as an expect of correct parent
> version usage [1] I get the error below when using current 3.4 master.
> Are you able to build the project successfully?

Sure you are running the ITs @HEAD? That's what Jenkins is running and
nothing fails there. The error message is what you get with the unfixed
IT and then is expected. When I say "local" vs. "remote" parent
resolution behave exactly the same there is one liddle difference left.
For local poms, there is no way to check the version range in use
contains an upper bound due to a different API in use. For external
poms, there is an additional check that the range does contain an upper
bound.

Do you really have projects where the <version> in <parent> is using a
version range and do inherit the project version from the parent? How
could you ever deploy something like that to a repository? Asking
because I'd like to understand why you could not notice that these
projects are not working as expected.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Igor Fedorenko <ig...@ifedorenko.com>]

I am sorry, Christian, I must be missing something obvious. When I try
building the IT project you suggested as an expect of correct parent
version usage [1] I get the error below when using current 3.4 master.
Are you able to build the project successfully?


[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the
POMs:
[FATAL] Version must be a constant @
org.apache.maven.its.mng2199:local-parent-module:[unknown-version],
/private/var/tmp/local-parent/module/pom.xml, line 2, column 10
 @
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project
org.apache.maven.its.mng2199:local-parent-module:1.1
(/private/var/tmp/local-parent/module/pom.xml) has 1 error
[ERROR]     Version must be a constant @
org.apache.maven.its.mng2199:local-parent-module:[unknown-version],
/private/var/tmp/local-parent/module/pom.xml, line 2, column 10
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException


[1]
https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=tree;f=core-it-suite/src/test/resources/mng-2199-parent-version-range;hb=HEAD

-- 
Regards,
Igor

On Sat, Nov 19, 2016, at 09:10 PM, Christian Schulte wrote:
> Am 11/20/16 um 02:56 schrieb Christian Schulte:
> > Am 11/20/16 um 00:12 schrieb Igor Fedorenko:
> >> Let me rephrase my question. What IT shows how to use parent version
> >> ranges with Maven 3.4?
> > 
> > MNG-2199
> > 
> > <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=tree;f=core-it-suite/src/test/resources/mng-2199-parent-version-range;hb=HEAD>
> > 
> > <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/java/org/apache/maven/it/MavenITmng2199ParentVersionRangeTest.java;h=7d77cb720ca27c46a4676faeb6244f46264edeac;hb=HEAD>
> 
> Re-reading that, the 'testValidLocalParentVersionRange' may still be
> incorrect. Maven does not fail the build when it cannot find a parent
> and just logs a warning about it. Seems that IT needs updating as well.
> It does not detect anything, I think. Not sure, though.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/20/16 um 02:56 schrieb Christian Schulte:
> Am 11/20/16 um 00:12 schrieb Igor Fedorenko:
>> Let me rephrase my question. What IT shows how to use parent version
>> ranges with Maven 3.4?
> 
> MNG-2199
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=tree;f=core-it-suite/src/test/resources/mng-2199-parent-version-range;hb=HEAD>
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/java/org/apache/maven/it/MavenITmng2199ParentVersionRangeTest.java;h=7d77cb720ca27c46a4676faeb6244f46264edeac;hb=HEAD>

Re-reading that, the 'testValidLocalParentVersionRange' may still be
incorrect. Maven does not fail the build when it cannot find a parent
and just logs a warning about it. Seems that IT needs updating as well.
It does not detect anything, I think. Not sure, though.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

When implementing parent version ranges, I also noticed MNG-5840. I did
not know what to do about it because there has been comments around
stating that the version is ingored intentionally somehow. I thought it
is intentional the local parent resolution is ignoring the version
element and did not change anything about it. The version ranges you
have been using, have been ignored completely. You could have left out
the version and your project would still work. Since MNG-5840 got fixed,
local parent resolution and external parent resolution behave exactly
the same.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/20/16 um 00:12 schrieb Igor Fedorenko:
> Let me rephrase my question. What IT shows how to use parent version
> ranges with Maven 3.4?

MNG-2199

<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=tree;f=core-it-suite/src/test/resources/mng-2199-parent-version-range;hb=HEAD>

<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/java/org/apache/maven/it/MavenITmng2199ParentVersionRangeTest.java;h=7d77cb720ca27c46a4676faeb6244f46264edeac;hb=HEAD>

It's easy. If the <version> in <parent> does not contain a version
range, nothing is different. If that element contains a version range,
the highest version found will be used and in addition, the project
version is no longer allowed to be inherited or to be declared using a
property.

> We actually use parent version ranges quite extensively internally, so I
> am trying to assess the impact of 3.4 changes for our users.

You are on a very dangerous road then. The <version> element in <parent>
elements has been ignored for all local poms (found using
<relativePath>) until <https://issues.apache.org/jira/browse/MNG-5840>
got fixed. Last commit for this issue was for Maven 3.3.9. You have not
noticed parent version ranges are not working since Maven 3.2.3 for poms
read from repositories. Means you are using version ranges in parent
elements solely for local poms? They never had been implemented there.
You could not notice this, because the <version> in <parent> just got
ignored completely. You could have written anything you like into it.

This commit
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=ed5ffbe5afc0be21f750f8cb8c95b6e9a3f3bd0c>
fixes an invalid IT. The IT did not test anything due to MNG-5840. You
could have left out the <version> in that module's <parent> completely
and that IT would have succeeded as well.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Igor Fedorenko <ig...@ifedorenko.com>]

Let me rephrase my question. What IT shows how to use parent version
ranges with Maven 3.4?

We actually use parent version ranges quite extensively internally, so I
am trying to assess the impact of 3.4 changes for our users.

-- 
Regards,
Igor

On Sat, Nov 19, 2016, at 05:57 PM, Christian Schulte wrote:
> Am 11/19/16 um 13:35 schrieb Igor Fedorenko:
> > What is parent version range syntax that works with 3.4? Or you are
> > saying parent version ranges are not supported at all now?
> 
> They got introduced in 3.2.2. This commit
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=6cf9320942c34bc68205425ab696b1712ace9ba4>
> about 2 weeks after the release of 3.2.2 broke parent version ranges.
> They have not been working from there on anymore in any Maven release.
> This commit
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=a6aca2894ab5a2849190cb802052710204081bf5>
> fixes the ITs so that they start detecting parent version ranges are not
> working. In between there have been commits fixing local parent
> resolution (readParentLocally).
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=40d5087b6b134842e2b61a567dbb4bfbcfab7ae6>
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=25f5143169d39075cee67d9f4d11649cce0fafa0>
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=bd87258629db8e3fcc7aa04777afc16314c3cde0>
> 
> When fixing the remote parent resolution (readParentExternally) for 3.4,
> I noticed the local parent resolution (readParentLocally) is lacking
> validation.
> 
> Maven 3.4 will be the first version ever supporting parent version
> ranges consistently for local and remote parents.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/19/16 um 13:35 schrieb Igor Fedorenko:
> What is parent version range syntax that works with 3.4? Or you are
> saying parent version ranges are not supported at all now?

They got introduced in 3.2.2. This commit
<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=6cf9320942c34bc68205425ab696b1712ace9ba4>
about 2 weeks after the release of 3.2.2 broke parent version ranges.
They have not been working from there on anymore in any Maven release.
This commit
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=a6aca2894ab5a2849190cb802052710204081bf5>
fixes the ITs so that they start detecting parent version ranges are not
working. In between there have been commits fixing local parent
resolution (readParentLocally).

<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=40d5087b6b134842e2b61a567dbb4bfbcfab7ae6>

<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=25f5143169d39075cee67d9f4d11649cce0fafa0>

<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=bd87258629db8e3fcc7aa04777afc16314c3cde0>

When fixing the remote parent resolution (readParentExternally) for 3.4,
I noticed the local parent resolution (readParentLocally) is lacking
validation.

Maven 3.4 will be the first version ever supporting parent version
ranges consistently for local and remote parents.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Igor Fedorenko <ig...@ifedorenko.com>]

What is parent version range syntax that works with 3.4? Or you are
saying parent version ranges are not supported at all now?

-- 
Regards,
Igor

On Fri, Nov 18, 2016, at 10:57 PM, Christian Schulte wrote:
> Am 11/19/16 um 03:58 schrieb Igor Fedorenko:
> > Thank you for the analysis of the IT failures, Christian. I have a few
> > questions/observations, if you don't mind
> > 
> > MavenITmng2199ParentVersionRangeTest.testValidLocalParentVersionRange
> > From what I can tell, module uses parent version=[1.0,2) which matches
> > locally available parent version=1.1. Can you explain why this test is
> > expected to fail? 
> 
> Put another way: You cannot deploy this module
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/resources/mng-2199-parent-version-range/local-parent/module/pom.xml;h=85769ce5af3a46f57ff4f15bb3faa366278d4cec;hb=b015e1cf9860fa9f3725a4393d7a0dc8a0868b2f>
> to a repository without a version. There is no way to add a dependency
> to this module. What version would you put into that dependency? The
> corresponding validation was missing in the core only for local parents.
> For parents resolved from repositories that module would never have
> worked. Just download Maven 3.2.2, remove that parent pom from disc and
> try building that module standalone. It will fail with an error message
> stating the version must be a constant as well.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/19/16 um 03:58 schrieb Igor Fedorenko:
> Thank you for the analysis of the IT failures, Christian. I have a few
> questions/observations, if you don't mind
> 
> MavenITmng2199ParentVersionRangeTest.testValidLocalParentVersionRange
> From what I can tell, module uses parent version=[1.0,2) which matches
> locally available parent version=1.1. Can you explain why this test is
> expected to fail? 

Put another way: You cannot deploy this module
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/resources/mng-2199-parent-version-range/local-parent/module/pom.xml;h=85769ce5af3a46f57ff4f15bb3faa366278d4cec;hb=b015e1cf9860fa9f3725a4393d7a0dc8a0868b2f>
to a repository without a version. There is no way to add a dependency
to this module. What version would you put into that dependency? The
corresponding validation was missing in the core only for local parents.
For parents resolved from repositories that module would never have
worked. Just download Maven 3.2.2, remove that parent pom from disc and
try building that module standalone. It will fail with an error message
stating the version must be a constant as well.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Igor Fedorenko <ig...@ifedorenko.com>]

Thank you for the analysis of the IT failures, Christian. I have a few
questions/observations, if you don't mind

MavenITmng2199ParentVersionRangeTest.testValidLocalParentVersionRange
From what I can tell, module uses parent version=[1.0,2) which matches
locally available parent version=1.1. Can you explain why this test is
expected to fail? 

MavenITmng4600DependencyOptionalFlagManagementTest/MNG-5227
This seems rather major dependency resolution change for 3.4 release,
but I do not have strong opinion about the change otherwise.

MavenITmng3719PomExecutionOrderingTest
Shows that Maven used to allow the same plugin used in multiple <plugin>
elements. I am actually surprised this worked in 3.3.9, but I think this
will be a real problem for project that rely on this behaviour.

For other MNG-6075 changes, again, this maybe little too big a change
for 3.4, but I think it is okay if remote pom.xml still work. Can you
confirm that Maven is still able to use "old" pom.xml file from remote
repositories?

MavenIT0051ReleaseProfileTest and MavenITmng5805PkgTypeMojoConfiguration
fail for me under Linux when using java7, but work on OSX with java8. I
did not investigate these further.

MavenITmng5640LifecycleParticipantAfterSessionEnd.testBuildErrorRt
worked for me under linux with java7 but failed on osx with java8. I did
not investigate this further.

I agree with the rest of your conclusion.

-- 
Regards,
Igor

On Thu, Nov 17, 2016, at 09:16 PM, Christian Schulte wrote:
> Am 11/17/16 um 21:43 schrieb Christian Schulte:
> > Am 11/17/16 um 06:00 schrieb Igor Fedorenko:
> >> FWIW, I ran maven integration tests (commit 73a2b7) against current
> >> maven master and got this
> >>
> >>> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0
> >>
> >> Running the same test checkout with Maven 3.3.9
> >>
> >>>  Tests run: 771, Failures: 0, Errors: 0, Skipped: 0
> 
> mng5783PluginDependencyFiltering(SLF4j)
> mng5742BuildExtensionClassloader(BuildExtensionClassloader)
> mng5578SessionScope(Basic_buildExtension)
> mng5578SessionScope(Basic_multithreaded)
> mng5753CustomMojoExecutionConfigurator(CustomMojoExecutionConfigurator)
> mng5530MojoExecutionScope(_copyfiles_multithreaded)
> mng5530MojoExecutionScope(Extension)
> mng5530MojoExecutionScope(_copyfiles)
> mng5805PkgTypeMojoConfiguration(PkgTypeMojoConfiguration)
> 
> These ITs needed updating due to the new default maven-plugin-plugin
> version in the 3.4 core. They are building 'maven-plugin' packaging
> projects and the updated maven-plugin-plugin needed them to be touched.
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=fe47f97e78537c74a98a23f5f70af3c02afe4d66>
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=946bba40683f278eb47bbeaaaf8c23c8a9ad249f>
> 
> Shouldn't be an issue. In Maven 3.4 you get a new default
> maven-plugin-plugin version uncovering issues like this. No need to
> revert anything, IMHO.
> 
> mng2199ParentVersionRange(InvalidParentVersionRange)
> mng2199ParentVersionRange(ValidLocalParentVersionRange)
> 
> These two ITs did not correctly detect parent version ranges are not
> working and got fixed by this commit:
> 
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=a6aca2894ab5a2849190cb802052710204081bf5>
> 
> They did not fail since 3.2.3 although they should have failed. Got
> fixed in 3.4. Nothing to worry about.
> 
> mng3843PomInheritance(itMNG3843)
> Expected to fail due to MNG-2478.
> 
> mng4600DependencyOptionalFlagManagement(itModel)
> Expected to fail due to MNG-5227. See
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=6d31bdd72116dc6cc8bfe6182321076b4b371558>
> 
> mng5640LifecycleParticipantAfterSessionEnd(BuildErrorRt)
> This one has not been changed in any way. I expect it to fail on my
> machine locally only? Does this one fail for you as well?
> 
> 0051ReleaseProfile(it0051)
> Expected to fail due to MNG-5940. See
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=e10c629bfcc3cdb6d24f386d7209d5402dad241b>.
> 
> mng1021EqualAttachmentBuildNumber(itMNG1021)
> mng1701DuplicatePlugin(it)
> mng3719PomExecutionOrdering(itMNG3719)
> mng4005UniqueDependencyKey(itManagedDependency)
> mng4005UniqueDependencyKey(itDependency)
> mng4005UniqueDependencyKey(itProfileDependency)
> mng4005UniqueDependencyKey(itProfileManagedDependency)
> Expected to fail due to MNG-6075. See
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=e7de36c506e8b0b442ffebdcd894bbb3600dfb26>.
> 
> mng3259DepsDroppedInMultiModuleBuild(itMNG3259)
> Expected to fail. See
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=bb1c2923f75547dc115307da3a64b1bf1938223a>.
> 
> mng5805PkgTypeMojoConfiguration(PkgTypeMojoConfiguration)
> Expected to fail due to MNG-5958. See
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=d0cab3ba34abb2732382ab8ef44f6a125e589970>.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/17/16 um 21:43 schrieb Christian Schulte:
> Am 11/17/16 um 06:00 schrieb Igor Fedorenko:
>> FWIW, I ran maven integration tests (commit 73a2b7) against current
>> maven master and got this
>>
>>> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0
>>
>> Running the same test checkout with Maven 3.3.9
>>
>>>  Tests run: 771, Failures: 0, Errors: 0, Skipped: 0

mng5783PluginDependencyFiltering(SLF4j)
mng5742BuildExtensionClassloader(BuildExtensionClassloader)
mng5578SessionScope(Basic_buildExtension)
mng5578SessionScope(Basic_multithreaded)
mng5753CustomMojoExecutionConfigurator(CustomMojoExecutionConfigurator)
mng5530MojoExecutionScope(_copyfiles_multithreaded)
mng5530MojoExecutionScope(Extension)
mng5530MojoExecutionScope(_copyfiles)
mng5805PkgTypeMojoConfiguration(PkgTypeMojoConfiguration)

These ITs needed updating due to the new default maven-plugin-plugin
version in the 3.4 core. They are building 'maven-plugin' packaging
projects and the updated maven-plugin-plugin needed them to be touched.

<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=fe47f97e78537c74a98a23f5f70af3c02afe4d66>

<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=946bba40683f278eb47bbeaaaf8c23c8a9ad249f>

Shouldn't be an issue. In Maven 3.4 you get a new default
maven-plugin-plugin version uncovering issues like this. No need to
revert anything, IMHO.

mng2199ParentVersionRange(InvalidParentVersionRange)
mng2199ParentVersionRange(ValidLocalParentVersionRange)

These two ITs did not correctly detect parent version ranges are not
working and got fixed by this commit:

<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=a6aca2894ab5a2849190cb802052710204081bf5>

They did not fail since 3.2.3 although they should have failed. Got
fixed in 3.4. Nothing to worry about.

mng3843PomInheritance(itMNG3843)
Expected to fail due to MNG-2478.

mng4600DependencyOptionalFlagManagement(itModel)
Expected to fail due to MNG-5227. See
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=6d31bdd72116dc6cc8bfe6182321076b4b371558>

mng5640LifecycleParticipantAfterSessionEnd(BuildErrorRt)
This one has not been changed in any way. I expect it to fail on my
machine locally only? Does this one fail for you as well?

0051ReleaseProfile(it0051)
Expected to fail due to MNG-5940. See
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=e10c629bfcc3cdb6d24f386d7209d5402dad241b>.

mng1021EqualAttachmentBuildNumber(itMNG1021)
mng1701DuplicatePlugin(it)
mng3719PomExecutionOrdering(itMNG3719)
mng4005UniqueDependencyKey(itManagedDependency)
mng4005UniqueDependencyKey(itDependency)
mng4005UniqueDependencyKey(itProfileDependency)
mng4005UniqueDependencyKey(itProfileManagedDependency)
Expected to fail due to MNG-6075. See
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=e7de36c506e8b0b442ffebdcd894bbb3600dfb26>.

mng3259DepsDroppedInMultiModuleBuild(itMNG3259)
Expected to fail. See
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commitdiff;h=bb1c2923f75547dc115307da3a64b1bf1938223a>.

mng5805PkgTypeMojoConfiguration(PkgTypeMojoConfiguration)
Expected to fail due to MNG-5958. See
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=d0cab3ba34abb2732382ab8ef44f6a125e589970>.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/17/16 um 06:00 schrieb Igor Fedorenko:
> FWIW, I ran maven integration tests (commit 73a2b7) against current
> maven master and got this
> 
>> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0
> 
> Running the same test checkout with Maven 3.3.9
> 
>>  Tests run: 771, Failures: 0, Errors: 0, Skipped: 0
> 

I am currently looking into this. Whenever I commit to maven master, I
start the 'maven-3.3-release-status' job on Jenkins and make sure, the
ITs will not fail there. I did not receive an email from Jenkins and
last time I started that job, the ITs ran successfully. I just started
that job again, it has not caught up with recent commits so far. Let's
see what will happen.

There is no reason for anyone to apologize for anything. This is email.
I am not sitting here with an angry face or something. It was more an
"oh fuck it. a few weeks ago postponed for 3.5, branch created, work
started to update JIRA issues, etc. and now it will not go into 3.x and
the next major version will not need any of those issues solved because
the new model solves all of them. what a waste of time."

There is one thing I think needs to be outlined. Jason, I know nothing
about the users you are talking about but I understand what is driving
your decisions. I have not worked on issues of any user I know of
personally. Every issue I have worked on has been reported by maven
users in JIRA. Maybe some of them are your users. I don't know. There is
no priority of my, your or anyone elses users here. If none of your
users report issues in JIRA, then why ignore the users doing that and
helping us by doing it. With "I did not change a thing" I meant "just
wait until master is in a state it will be released in". There are ways
to ship those changes without breaking backwards compatibility without
the need to update model versions or something like this. I am currently
working on making the one behavioural change not backwards compatible
controllable by using a POM property
'maven.model.dependencyManagementImportInheritanceProcessing'
(true/false). It's done that way in other areas. Similar to this [1] but
without changing the maven model. POM property instead of model
attribute. Would you be against doing that as well? If the anser is yes,
then at least the Springframework guys and theire users will be
disappointed when not shipping MNG-5971 for model version 4.0.0 in some
backwards compatible way.

[1]
<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=4dde52072559d34feafb72f3784c265aacb14c8e>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/17/16 um 06:00 schrieb Igor Fedorenko:
> FWIW, I ran maven integration tests (commit 73a2b7) against current
                                              ^^^^^^

Running this commit against 3.4.0-SNAPSHOT now locally. I expect some
ITs to fail. There have been updates to a few tests adding a 3.4 upper
bound and a new test with lower bound 3.4. I will take a look at it
again when the tests have completed. There are tests on master with
lower bound 3.5 already. I will just delete them as they were added for
3.4 by me than updated to run with 3.5 and - well - as it seems will
never have to run with any maven version as of yesterday. Ever run that
commit against Maven 3.0 or even 2.0? Not reacting to those commit mails
send out for every commit and then coming up with this one year later.
Come on. Have you been sleeping on commits@ ;-) ?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Igor Fedorenko <ig...@ifedorenko.com>]

FWIW, I ran maven integration tests (commit 73a2b7) against current
maven master and got this

> Tests run: 771, Failures: 3, Errors: 21, Skipped: 0

Running the same test checkout with Maven 3.3.9

>  Tests run: 771, Failures: 0, Errors: 0, Skipped: 0

-- 
Regards,
Igor

On Wed, Nov 16, 2016, at 11:02 PM, Jason van Zyl wrote:
> So have you not asked, after committing changes, if something should not
> be rolled back? If you can take the integration tests from the commit
> right after the 3.3.9 release and Maven master works against that I’ll be
> perfectly satisfied that we will not be breaking the user base.
> 
> > On Nov 15, 2016, at 3:42 PM, Christian Schulte <cs...@schulte.it> wrote:
> > 
> > Am 11/15/16 um 23:41 schrieb Jason van Zyl:
> >> 
> >> You obviously don’t work with anyone who has a system with any number of users. No one has said the system cannot change, but you repeatedly keep changing stuff that potentially has huge impacts on users and it doesn’t bother you at all. I just really don’t think you’ve ever had to deal with more than a few users. Almost none of the changes are well documented, there’s no release notes, we’ve told you to roll back or stop making behavioral changes. It currently may not be ideal, we all may consider it’s a bug, or we may all agree it’s wrong. A minor version is not the time or place to change it.
> >> 
> > 
> > Damn it. I haven't changed a thing and have been asking on how those
> > changes can be integrated. I would like to avoid loosing track here.
> > Give me a branch I can commit things like that to and I'll be done with
> > it and can forget about it. That's all. That branch needs to be
> > something permanent others can integrate into as well. And it needs to
> > be clear what version is in those poms on that branch. 4.0.0-SNAPHOT,
> > 5.0.0-SNAPSHOT, what? Based on what you just said, the 'maven-3.x-next'
> > branch is not the right place for this so that I can delete it. If you
> > look at <https://issues.apache.org/jira/browse/MNG-6056>, that's also
> > nothing we could do for 3.5. And I'll need to revert bug 486740 in the
> > maven resolver now as well, as that bug fix also cannot be shipped
> > according to what you just said. I am running circles and would like to
> > just finish up on various things so that I can forget about them. It's
> > good that there is MRESOLVER in JIRA now. I could attach patches there,
> > for example.
> > 
> >> Such is life. Again if you want to make drastic changes take all your changes and put them on a 4.0 branch and do whatever you want. It’s an open source project so you’re free to do so. Changing behavior and changing tests that validate that behavior is just really such a bad, bad idea. Please go make a 4.0 branch and feel free to do whatever you want.
> > 
> > That's all there is to it. Should I put 4.0.0-SNAPSHOT into those POMs?
> > Could someone create a matching version in JIRA then, please? And a next
> > version for MRESOLVER as well, please, where things like that can be
> > tracked with. Can we please line up all of this with everyone and with
> > whatever changes others have in mind.
> > 
> > Regarding the tests. I absolutely disagree in the way those tests have
> > been written. For example:
> > 
> > When that specific IT has been written, there should have been a plan on
> > how that will have to look in the future. I mean:
> > 
> > super( "[2.0.6,)" );
> > 
> > in that constructor with no upper bound although the author himself knew
> > that this behaviour will change in the future is what requires it to be
> > changed. There should have been an upper bound right from the start: For
> > example:
> > 
> > super( "[2.0.6,3.0)"),
> > 
> > and a corrosponding test with
> > 
> > super( "[3.0,)" );
> > 
> > when known that the test is really testing the "final" behaviour. So
> > this missing upper bound is what is requiring changing that IT. The
> > author knew that test will not be valid for all upcoming Maven versions
> > but had no idea on what upper bound to use. Reviewing all those ITs is a
> > huge effort due to this. Fix something, review all failing ITs and
> > decide on what test is incorrect is something very error prone. That's
> > just trial and error and will not solve things like this once and for all.
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> > 
> 
> Thanks,
> 
> Jason
> 
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Jason van Zyl <ja...@takari.io>]

So have you not asked, after committing changes, if something should not be rolled back? If you can take the integration tests from the commit right after the 3.3.9 release and Maven master works against that I’ll be perfectly satisfied that we will not be breaking the user base.

> On Nov 15, 2016, at 3:42 PM, Christian Schulte <cs...@schulte.it> wrote:
> 
> Am 11/15/16 um 23:41 schrieb Jason van Zyl:
>> 
>> You obviously don’t work with anyone who has a system with any number of users. No one has said the system cannot change, but you repeatedly keep changing stuff that potentially has huge impacts on users and it doesn’t bother you at all. I just really don’t think you’ve ever had to deal with more than a few users. Almost none of the changes are well documented, there’s no release notes, we’ve told you to roll back or stop making behavioral changes. It currently may not be ideal, we all may consider it’s a bug, or we may all agree it’s wrong. A minor version is not the time or place to change it.
>> 
> 
> Damn it. I haven't changed a thing and have been asking on how those
> changes can be integrated. I would like to avoid loosing track here.
> Give me a branch I can commit things like that to and I'll be done with
> it and can forget about it. That's all. That branch needs to be
> something permanent others can integrate into as well. And it needs to
> be clear what version is in those poms on that branch. 4.0.0-SNAPHOT,
> 5.0.0-SNAPSHOT, what? Based on what you just said, the 'maven-3.x-next'
> branch is not the right place for this so that I can delete it. If you
> look at <https://issues.apache.org/jira/browse/MNG-6056>, that's also
> nothing we could do for 3.5. And I'll need to revert bug 486740 in the
> maven resolver now as well, as that bug fix also cannot be shipped
> according to what you just said. I am running circles and would like to
> just finish up on various things so that I can forget about them. It's
> good that there is MRESOLVER in JIRA now. I could attach patches there,
> for example.
> 
>> Such is life. Again if you want to make drastic changes take all your changes and put them on a 4.0 branch and do whatever you want. It’s an open source project so you’re free to do so. Changing behavior and changing tests that validate that behavior is just really such a bad, bad idea. Please go make a 4.0 branch and feel free to do whatever you want.
> 
> That's all there is to it. Should I put 4.0.0-SNAPSHOT into those POMs?
> Could someone create a matching version in JIRA then, please? And a next
> version for MRESOLVER as well, please, where things like that can be
> tracked with. Can we please line up all of this with everyone and with
> whatever changes others have in mind.
> 
> Regarding the tests. I absolutely disagree in the way those tests have
> been written. For example:
> 
> When that specific IT has been written, there should have been a plan on
> how that will have to look in the future. I mean:
> 
> super( "[2.0.6,)" );
> 
> in that constructor with no upper bound although the author himself knew
> that this behaviour will change in the future is what requires it to be
> changed. There should have been an upper bound right from the start: For
> example:
> 
> super( "[2.0.6,3.0)"),
> 
> and a corrosponding test with
> 
> super( "[3.0,)" );
> 
> when known that the test is really testing the "final" behaviour. So
> this missing upper bound is what is requiring changing that IT. The
> author knew that test will not be valid for all upcoming Maven versions
> but had no idea on what upper bound to use. Reviewing all those ITs is a
> huge effort due to this. Fix something, review all failing ITs and
> decide on what test is incorrect is something very error prone. That's
> just trial and error and will not solve things like this once and for all.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/15/16 um 23:41 schrieb Jason van Zyl:
> 
> You obviously don\u2019t work with anyone who has a system with any number of users. No one has said the system cannot change, but you repeatedly keep changing stuff that potentially has huge impacts on users and it doesn\u2019t bother you at all. I just really don\u2019t think you\u2019ve ever had to deal with more than a few users. Almost none of the changes are well documented, there\u2019s no release notes, we\u2019ve told you to roll back or stop making behavioral changes. It currently may not be ideal, we all may consider it\u2019s a bug, or we may all agree it\u2019s wrong. A minor version is not the time or place to change it.
> 

Damn it. I haven't changed a thing and have been asking on how those
changes can be integrated. I would like to avoid loosing track here.
Give me a branch I can commit things like that to and I'll be done with
it and can forget about it. That's all. That branch needs to be
something permanent others can integrate into as well. And it needs to
be clear what version is in those poms on that branch. 4.0.0-SNAPHOT,
5.0.0-SNAPSHOT, what? Based on what you just said, the 'maven-3.x-next'
branch is not the right place for this so that I can delete it. If you
look at <https://issues.apache.org/jira/browse/MNG-6056>, that's also
nothing we could do for 3.5. And I'll need to revert bug 486740 in the
maven resolver now as well, as that bug fix also cannot be shipped
according to what you just said. I am running circles and would like to
just finish up on various things so that I can forget about them. It's
good that there is MRESOLVER in JIRA now. I could attach patches there,
for example.

> Such is life. Again if you want to make drastic changes take all your changes and put them on a 4.0 branch and do whatever you want. It\u2019s an open source project so you\u2019re free to do so. Changing behavior and changing tests that validate that behavior is just really such a bad, bad idea. Please go make a 4.0 branch and feel free to do whatever you want.

That's all there is to it. Should I put 4.0.0-SNAPSHOT into those POMs?
Could someone create a matching version in JIRA then, please? And a next
version for MRESOLVER as well, please, where things like that can be
tracked with. Can we please line up all of this with everyone and with
whatever changes others have in mind.

Regarding the tests. I absolutely disagree in the way those tests have
been written. For example:

When that specific IT has been written, there should have been a plan on
how that will have to look in the future. I mean:

super( "[2.0.6,)" );

in that constructor with no upper bound although the author himself knew
that this behaviour will change in the future is what requires it to be
changed. There should have been an upper bound right from the start: For
example:

super( "[2.0.6,3.0)"),

and a corrosponding test with

super( "[3.0,)" );

when known that the test is really testing the "final" behaviour. So
this missing upper bound is what is requiring changing that IT. The
author knew that test will not be valid for all upcoming Maven versions
but had no idea on what upper bound to use. Reviewing all those ITs is a
huge effort due to this. Fix something, review all failing ITs and
decide on what test is incorrect is something very error prone. That's
just trial and error and will not solve things like this once and for all.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/17/16 um 23:56 schrieb Christian Schulte:
> Am 11/15/16 um 23:41 schrieb Jason van Zyl:
>> Almost none of the changes are well documented, there\u2019s no release notes, we\u2019ve told you to roll back or stop making behavioral changes.

Put another way. Please take a look at the following constants in
current master DefaultModelBuilder. If you say roll back, you can do
that yourself easily by updating those constants to look like:

DEPENDENCY_MANAGEMENT_IMPORT_VERSION_RANGES = false;
DEPENDENCY_MANAGEMENT_IMPORT_EXCLUSIONS = false;
DEPENDENCY_MANAGEMENT_IMPORT_RELOCATIONS = false;
DEPENDENCY_MANAGEMENT_IMPORT_INHERITANCE_PROCESSING = false;

No more system properties and the model builder will not change behavior
any more. The last property has been requested to default to 'true'. In
JIRA, on users@ by independent parties. Just set all those constants to
false and things are rolled back. My proposal is to make the

DEPENDENCY_MANAGEMENT_IMPORT_INHERITANCE_PROCESSING

property a POM property
'maven.model.dependencyManagementImportInheritanceProcessing'. If that
property is 'true', import scope of *that* POM will be processed
differently. Older Maven versions do not understand that property, of
course. No way - don't do that? Just set that constant to false and be
done with it. I need to update the JIRA issue once more telling those
guys that it will not be part of 3.4 or any other 3.x Maven version
because it won't pass a release vote. Case closed. Just say: "Don't do
it that way because older Maven versions would start building a
different effective model than more recent Maven versions" and the next
commit will set it to false once and for all. Someone wanting it, can
patch Maven himself and use that patched version. It's easy based on
what we now have on master.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/15/16 um 23:41 schrieb Jason van Zyl:
> Almost none of the changes are well documented, there\u2019s no release notes, we\u2019ve told you to roll back or stop making behavioral changes.

Do you notice how many times I reverted things, changed things,
re-reverted things, tried it in a backwards compatible way, reverted,
tried again but differently, reverted? I am not kean to do the same with
the site or the release notes. I am still trying to provide the
behavioral changes in a backwards compatible way so that users can opt
in solely based on the POM (properties in the POM). That way there are
no behavioral changes and Maven does the "right" thing solely based on
information from the POMs it builds. Updating the site, writing release
notes etc. is one of the very last steps. Current master still is WIP
and will keep changing until everyone agrees to it so that we can
release it without anyone getting into trouble. There will be a final
version ready for release solving all complaints and issues and there
will be documentation and release notes. This will take time. Is there
some kind of hurry?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Jason van Zyl <ja...@takari.io>]

> On Nov 15, 2016, at 12:31 PM, Christian Schulte <cs...@schulte.it> wrote:
> 
> Am 11/15/16 um 17:17 schrieb Jason van Zyl:
>> -1
>> 
>> No one has likely to have read the information
> 
> The reporter of the issue clearly has ;-)
> 
>> and you’re reasoning is illogical.
> 
> Making Maven behave as advertised and as requested isn't that illogical,
> IMHO.
> 

How it’s advertised is how it’s currently distributed and been working for years. You think it’s logical the code to match documentation versus changing the documentation to match what has been working in a specific say for years?

>> Repeatedly you seem not to care if you’re going to break a users build because of lack of adherence to what you think is right.
> 
> The builds already are broken.

Define broken? You’re saying people are using this as-is and their builds are failing?

> I do not want the dependency management
> of a library I consume to be ignored by Maven making the dependency
> graph the way it gets consumed differ to what it looked like when
> deployed. Not only the reporter noticed this. See below. We could put
> that the other way around by saying "you seem not to care to fix broken
> builds" but that's just unproductive and leads to nowhere. There is at
> least one reporter who created an issue in JIRA telling us his builds
> are not working as advertised and who has put effort into reporting this
> to us. Having looked at it, that guy is just right. Working on it, I ran
> into an IT [1] starting to fail carrying this comment:
> 
> "should better have been excluded as well, now it's a matter of
> backward-compat"
> 
> So the author of that IT already knew things aren't correct but has kept
> things the way they were for Maven 2 backwards compatibility. I wish he
> would have fixed that six years ago, by the way.
> 

So you’re going to base your change in a minor version based on one reporter? 

>> What’s “right” is the way it currently works within this minor
>> version.
> 
> I take this as an example of what I am trying to stop.
> 

You obviously don’t work with anyone who has a system with any number of users. No one has said the system cannot change, but you repeatedly keep changing stuff that potentially has huge impacts on users and it doesn’t bother you at all. I just really don’t think you’ve ever had to deal with more than a few users. Almost none of the changes are well documented, there’s no release notes, we’ve told you to roll back or stop making behavioral changes. It currently may not be ideal, we all may consider it’s a bug, or we may all agree it’s wrong. A minor version is not the time or place to change it.

> 1. MNG-4720 created 08/Jul/10 14:48
> 2. IT capturing the known misbehaviour created 2010-07-08
> 3. MNG-5761 created 04/Feb/15 13:24
> 4. Fixed by me in mid 2016
> 5. Reverted and postponed for maybe 3.5 or 5.0 or whenever.
> 
> That's a history repeating. There is a - I guess - *new* user starting
> to use Maven. That user has read the documentation and that has created
> various expectations on how things are behaving.

Then fix the docs.

> That user then tests
> his builds and starts wondering why things are not working as expected.

To assume this happens on a wide scale is speculation.

> Puts effort into reporting an issue we know exists for - as of today -
> six years. We need to find a way out of this so that *new* users do no
> longer run into issues we could have fixed nearly a decade ago but did
> not. Maven 2 is EOL. We have not fixed Maven 2 misbehaviour in Maven 3.
> So we should EOL Maven 3 and provide something fixing those things finally.

Such is life. Again if you want to make drastic changes take all your changes and put them on a 4.0 branch and do whatever you want. It’s an open source project so you’re free to do so. Changing behavior and changing tests that validate that behavior is just really such a bad, bad idea. Please go make a 4.0 branch and feel free to do whatever you want.

> 
> [1]
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusionMergeTest.java;h=752ef8763893955f07ac48e0ced2cb86edae0ec8;hb=HEAD#l68>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Christian Schulte <cs...@schulte.it>]

Am 11/15/16 um 17:17 schrieb Jason van Zyl:
> -1
> 
> No one has likely to have read the information

The reporter of the issue clearly has ;-)

> and you\u2019re reasoning is illogical.

Making Maven behave as advertised and as requested isn't that illogical,
IMHO.

> Repeatedly you seem not to care if you\u2019re going to break a users build because of lack of adherence to what you think is right.

The builds already are broken. I do not want the dependency management
of a library I consume to be ignored by Maven making the dependency
graph the way it gets consumed differ to what it looked like when
deployed. Not only the reporter noticed this. See below. We could put
that the other way around by saying "you seem not to care to fix broken
builds" but that's just unproductive and leads to nowhere. There is at
least one reporter who created an issue in JIRA telling us his builds
are not working as advertised and who has put effort into reporting this
to us. Having looked at it, that guy is just right. Working on it, I ran
into an IT [1] starting to fail carrying this comment:

"should better have been excluded as well, now it's a matter of
backward-compat"

So the author of that IT already knew things aren't correct but has kept
things the way they were for Maven 2 backwards compatibility. I wish he
would have fixed that six years ago, by the way.

> What\u2019s \u201cright\u201d is the way it currently works within this minor
> version.

I take this as an example of what I am trying to stop.

1. MNG-4720 created 08/Jul/10 14:48
2. IT capturing the known misbehaviour created 2010-07-08
3. MNG-5761 created 04/Feb/15 13:24
4. Fixed by me in mid 2016
5. Reverted and postponed for maybe 3.5 or 5.0 or whenever.

That's a history repeating. There is a - I guess - *new* user starting
to use Maven. That user has read the documentation and that has created
various expectations on how things are behaving. That user then tests
his builds and starts wondering why things are not working as expected.
Puts effort into reporting an issue we know exists for - as of today -
six years. We need to find a way out of this so that *new* users do no
longer run into issues we could have fixed nearly a decade ago but did
not. Maven 2 is EOL. We have not fixed Maven 2 misbehaviour in Maven 3.
So we should EOL Maven 3 and provide something fixing those things finally.

[1]
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusionMergeTest.java;h=752ef8763893955f07ac48e0ced2cb86edae0ec8;hb=HEAD#l68>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [MNG-5761] Dependency management is not transitive.

[Jason van Zyl <ja...@takari.io>]

-1

No one has likely to have read the information and you’re reasoning is illogical. Repeatedly you seem not to care if you’re going to break a users build because of lack of adherence to what you think is right.

What’s “right” is the way it currently works within this minor version.

> On Nov 14, 2016, at 4:01 PM, Christian Schulte <cs...@schulte.it> wrote:
> 
> Hi,
> 
> starting to write up some documentation for 3.4.0 has lead to (re-)
> reading various parts of the existing documentation. Regarding the issue
> in the subject. Would it be ok to include the corresponding fix in
> 3.4.0? It makes Maven 3.4.0 dependency management behave exactly as it
> is documented. Currently dependency management really is not transitive
> and is still kept compatible to Maven 2 (broken behaviour). Fix would be
> to replace ClassicDependencyManager [1] with TransitiveDependencyManaget
> [1]. This is one of things postponed a few months ago when the maven
> resolver was on its way. Now that it's there, I see no reason to not
> include that fix in 3.4.0. Why keep things still compatible to Maven 2
> when that is EOL? WDYT?
> 
> [1]
> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=tree;f=maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager;h=79506b8e925b5586c8065204997ead06245686bf;hb=HEAD>
> 
> Regards,
> -- 
> Christian
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org