Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/20/16 um 01:58 schrieb Christian Schulte:
> 2. Collect dependency
> -
> CollectRequest.setRoot(Dependency):
> The dependency passed to this method is some *direct* dependency you got
> from somewhere. Management is considered to already be applied. This
> will become the root node of the result tree.
> 
> CollectRequest.addDependency(Dependency):
> The dependencies passed to this method are considered to be *transitive*
> dependencies of the root dependency. The resolver will apply management
> to them. See above. That is different. Here they are transitive, whereas
> above they are direct. This is what was not handled consistently accross
> the various selectors.

The Javadoc clearly states the 'addDependency' method to take direct
dependencies. It may well be that I took the incorrect selector and made
the others behave the same although I should have fixed that one
selector to match the others. That's the minefield. Will take a look
again. The result is the same. So whatever that leads to will not change
the behaviour you are now seeing on master.


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/19/16 um 18:26 schrieb Stephen Connolly:
> We need to clarify.
> 
> There is stuff that is "wrong" but has become expected behaviour because we
> never "fixed" it => we cannot "fix" now because it will break too many users
> 
> There is stuff that is "wrong" because we broke it, some users have
> legitimate bugs and other users have hacks around the "wrong" => we will
> break something no matter what we do, so maybe we can "fix"
> 
> There is stuff that is "wrong" because it was never specified and we'd now
> like it to work one way because that way feels "right"
> 
> Etc
> 
> What class of problem is this?
> 
> To my mind, depMgmt should never alter the scope of a dependency... if you
> specify a scope you are saying apply the rest when it is added with this
> scope.
> 
> But that is my "how I would like it to work"...
> 
> Christian, you need to identify which kind of "wrong" behaviour is going on
> here... then we can reframe the debate and find a path forward

That's by far not easy. I maybe should explain where most of this comes
from. Working on an issue, I read a lot from the
'DefaultDependencyCollector' and involved classes from the resolver.
That's like walking in a minefield. Also for the original author. During
reading, I found some inconsistencies between various
'DependencySelector' implementations which happened to be the cause for
the issue I was working on. I took the one implementation I understood
was working as intendend and made two others match that logic (decide if
a depencency is transitive or direct). Then wrote test cases for all of
this to test they all behave the same. What influences the transitive
vs. direct logic is how the 'CollectRequest' has been populated. For
project resolution, the 'setRootArtifact(POM)' method should be used,
for dependency resolution the 'setRoot(Dependency)' method should be used.



This has a direct impact on the way the following methods need to decide
transitive vs. direct.

'deriveChildSelector' here:



'deriveChildManager' here:



'deriveChildTraverser' here:



'deriveChildFilter' here:



Implementations in use are here:


Sometime back in time, this difference between POM resolution and
dependency resolution must have been introduced without all those
'deriveXyz' implementations having been updated to reflect that
difference. That's what I did. They now all behave the same and
correctly decide transitive vs. direct based on what the
'CollectRequest' has been setup to. The core use-cases are the following:

1. Collect project
--
CollectRequest.setRootArtifact(Artifact):
The artifact passed to this method is a project. This will become the
root node of the result tree.

CollectRequest.addDependency(Dependency):
The dependencies passed to this method are the *direct* dependencies of
that POM the way the core model builder has build/managed them.

CollectRequest.addManagedDependency(Dependency):
The management from the POM to be applied to *transitive* dependencies.
The direct dependencies already have been managed by the core model
builder. Whereas the model builder only manages elements not declared
directly, the resolver overrides all elements (it cannot know if a
mandatory element has been declared directly or has been managed by the
core model builder because the elements are just there.)

2. Collect dependency
-
CollectRequest.setRoot(Dependency):
The dependency passed to this method is some *direct* dependency you got
from somewhere. Management is considered to already be applied. This
will become the root node of the result tree.

CollectRequest.addDependency(Dependency):
The dependencies passed to this method are considered to be *transitive*
dependencies of the root dependency. The resolver 

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Stephen Connolly]

We need to clarify.

There is stuff that is "wrong" but has become expected behaviour because we
never "fixed" it => we cannot "fix" now because it will break too many users

There is stuff that is "wrong" because we broke it, some users have
legitimate bugs and other users have hacks around the "wrong" => we will
break something no matter what we do, so maybe we can "fix"

There is stuff that is "wrong" because it was never specified and we'd now
like it to work one way because that way feels "right"

Etc

What class of problem is this?

To my mind, depMgmt should never alter the scope of a dependency... if you
specify a scope you are saying apply the rest when it is added with this
scope.

But that is my "how I would like it to work"...

Christian, you need to identify which kind of "wrong" behaviour is going on
here... then we can reframe the debate and find a path forward

- Stephen

On Sun 18 Dec 2016 at 23:52, Christian Schulte  wrote:

> Am 12/18/16 um 13:36 schrieb Robert Scholte:
>
> > On Fri, 16 Dec 2016 21:23:14 +0100, Christian Schulte 
>
> > wrote:
>
> >
>
> >> Am 12/16/16 um 20:30 schrieb Robert Scholte:
>
> >>> On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte 
>
> >>> wrote:
>
> >>>
>
>  Am 12/16/16 um 15:21 schrieb Robert Scholte:
>
> >
>
> > but this cover the issue we are talking about, because IIUC you are
>
> > saying
>
> > that IF both junit and hamcrest get the test-scope AND hamcrest would
>
> > have
>
> > a dependency THEN that dependency is not added to the classpath. That
>
> > is
>
> > still unexpected behavior.
>
> 
>
>  Just add 'test' scope to the hamcrest dependency in that pom. It will
>
>  disappear from the classpath. I would expect that to happen. Why
> should
>
>  it manage the version but not the scope?
>
> 
>
> >>>
>
> >>> Because Junit refers to hamcrest classes, so they are required to be
>
> >>> able
>
> >>> to compile.
>
> >>> There is an issue about this, that Maven should never reduce the scope.
>
> >>
>
> >> It's not Maven reducing any scope, it's the user telling Maven to do
>
> >> that. The user is the dependency manager, not Maven.
>
> >>
>
> >
>
> > No, no, no. Dependency management may never make dependencies disappear,
>
> > no matter the scope specified. If a user doesn't want a dependency, it
>
> > must use dependency.excludes.
>
>
>
> Managing the scope of a dependency to 'test' Maven must behave the same
>
> way as if the dependency had been declared 'test' directly in the POM.
>
> That's the point. That's what dependency management is used for. Manage
>
> dependencies not in your control (global override to what is in the POM
>
> during resolution).
>
>
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/18/16 um 13:36 schrieb Robert Scholte:
> On Fri, 16 Dec 2016 21:23:14 +0100, Christian Schulte   
> wrote:
> 
>> Am 12/16/16 um 20:30 schrieb Robert Scholte:
>>> On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte 
>>> wrote:
>>>
 Am 12/16/16 um 15:21 schrieb Robert Scholte:
>
> but this cover the issue we are talking about, because IIUC you are
> saying
> that IF both junit and hamcrest get the test-scope AND hamcrest would
> have
> a dependency THEN that dependency is not added to the classpath. That  
> is
> still unexpected behavior.

 Just add 'test' scope to the hamcrest dependency in that pom. It will
 disappear from the classpath. I would expect that to happen. Why should
 it manage the version but not the scope?

>>>
>>> Because Junit refers to hamcrest classes, so they are required to be  
>>> able
>>> to compile.
>>> There is an issue about this, that Maven should never reduce the scope.
>>
>> It's not Maven reducing any scope, it's the user telling Maven to do
>> that. The user is the dependency manager, not Maven.
>>
> 
> No, no, no. Dependency management may never make dependencies disappear,  
> no matter the scope specified. If a user doesn't want a dependency, it  
> must use dependency.excludes.

Managing the scope of a dependency to 'test' Maven must behave the same
way as if the dependency had been declared 'test' directly in the POM.
That's the point. That's what dependency management is used for. Manage
dependencies not in your control (global override to what is in the POM
during resolution).


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Robert Scholte]

On Fri, 16 Dec 2016 21:23:14 +0100, Christian Schulte   
wrote:



Am 12/16/16 um 20:30 schrieb Robert Scholte:

On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte 
wrote:


Am 12/16/16 um 15:21 schrieb Robert Scholte:


but this cover the issue we are talking about, because IIUC you are
saying
that IF both junit and hamcrest get the test-scope AND hamcrest would
have
a dependency THEN that dependency is not added to the classpath. That  
is

still unexpected behavior.


Just add 'test' scope to the hamcrest dependency in that pom. It will
disappear from the classpath. I would expect that to happen. Why should
it manage the version but not the scope?



Because Junit refers to hamcrest classes, so they are required to be  
able

to compile.
There is an issue about this, that Maven should never reduce the scope.


It's not Maven reducing any scope, it's the user telling Maven to do
that. The user is the dependency manager, not Maven.



No, no, no. Dependency management may never make dependencies disappear,  
no matter the scope specified. If a user doesn't want a dependency, it  
must use dependency.excludes.


Robert


Suppose the user wasn't aware that hamcrest is a runtime requirement of
JUnit and simply adds it for his own test there as test-scoped  
dependency

you will have a surprising effect.
I am of course aware that (currently) a dependency can only have one
version and one scope. However, I would love to go for a different
approach: choose one or more scopes and select all their matching
dependencies + transitive dependencies. Reflecting this to your example
hamcrest would always be selected as transitive dependency of junit and
its scope will be ignored.
This matches much better the real world expected behavior no matter what
the Maven documentation says.


The following is status quo:

The core (model builder) uses the dependency management as a source of
default values it will copy to all dependencies lacking the
corresponding elements. The resolver uses the dependency management
passed to it as a source of effective values it will apply just like a
global override.

Prior 3.4, the dependency collection process looked like:

1. Request to resolve a dependency.
2. Query the repository system session's 'DependencySelector' to see if
the dependency should be selected.
3. Override everything of that dependency with any requested management.
4. Do everything else (transformations and conflict resolution) with
that managed state.

In 3.4, the dependency collection process now looks like:

1. Request to resolve a dependency.
2. Override everything of that dependency with any requested management.
3. Query the repository system session's 'DependencySelector' to see if
the dependency should be selected.
4. Do everything else (transformations and conflict resolution) with
that managed state.

It just calls the 'DependencySelector' with the managed state the same
way it performs everything else with the managed state. The dependency
selector in use happens to be setup to exclude "test", "provided" and
"optional" transitive dependencies. Why is that correct? If the
"DependencySelector" decides a "runtime" scoped dependency is to be
selected and the very next step makes it a "test" scoped dependency,
that dependency influences everything else in an unexpected way. The
conflict resolver may decide to keep that managed "test" scope
dependency over another node although that other node is what users
would have expected to be collected. So what we now have on master is
just behaving consistently with itself. The pom and the description from
that mail is the example for the release notes, BTW.


Btw, this looks very close to
https://issues.apache.org/jira/browse/MNG-6058


MNG-6058 cannot be solved with model version 4.0.0.

Regards,


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/16/16 um 20:30 schrieb Robert Scholte:
> On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte   
> wrote:
> 
>> Am 12/16/16 um 15:21 schrieb Robert Scholte:
>>>
>>> but this cover the issue we are talking about, because IIUC you are  
>>> saying
>>> that IF both junit and hamcrest get the test-scope AND hamcrest would  
>>> have
>>> a dependency THEN that dependency is not added to the classpath. That is
>>> still unexpected behavior.
>>
>> Just add 'test' scope to the hamcrest dependency in that pom. It will
>> disappear from the classpath. I would expect that to happen. Why should
>> it manage the version but not the scope?
>>
> 
> Because Junit refers to hamcrest classes, so they are required to be able  
> to compile.
> There is an issue about this, that Maven should never reduce the scope. 

It's not Maven reducing any scope, it's the user telling Maven to do
that. The user is the dependency manager, not Maven.

> Suppose the user wasn't aware that hamcrest is a runtime requirement of  
> JUnit and simply adds it for his own test there as test-scoped dependency  
> you will have a surprising effect.
> I am of course aware that (currently) a dependency can only have one  
> version and one scope. However, I would love to go for a different  
> approach: choose one or more scopes and select all their matching  
> dependencies + transitive dependencies. Reflecting this to your example  
> hamcrest would always be selected as transitive dependency of junit and  
> its scope will be ignored.
> This matches much better the real world expected behavior no matter what  
> the Maven documentation says.

The following is status quo:

The core (model builder) uses the dependency management as a source of
default values it will copy to all dependencies lacking the
corresponding elements. The resolver uses the dependency management
passed to it as a source of effective values it will apply just like a
global override.

Prior 3.4, the dependency collection process looked like:

1. Request to resolve a dependency.
2. Query the repository system session's 'DependencySelector' to see if
the dependency should be selected.
3. Override everything of that dependency with any requested management.
4. Do everything else (transformations and conflict resolution) with
that managed state.

In 3.4, the dependency collection process now looks like:

1. Request to resolve a dependency.
2. Override everything of that dependency with any requested management.
3. Query the repository system session's 'DependencySelector' to see if
the dependency should be selected.
4. Do everything else (transformations and conflict resolution) with
that managed state.

It just calls the 'DependencySelector' with the managed state the same
way it performs everything else with the managed state. The dependency
selector in use happens to be setup to exclude "test", "provided" and
"optional" transitive dependencies. Why is that correct? If the
"DependencySelector" decides a "runtime" scoped dependency is to be
selected and the very next step makes it a "test" scoped dependency,
that dependency influences everything else in an unexpected way. The
conflict resolver may decide to keep that managed "test" scope
dependency over another node although that other node is what users
would have expected to be collected. So what we now have on master is
just behaving consistently with itself. The pom and the description from
that mail is the example for the release notes, BTW.

> Btw, this looks very close to
> https://issues.apache.org/jira/browse/MNG-6058

MNG-6058 cannot be solved with model version 4.0.0.

Regards,
-- 
Christian


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Robert Scholte]

On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte   
wrote:



Am 12/16/16 um 15:21 schrieb Robert Scholte:


but this cover the issue we are talking about, because IIUC you are  
saying
that IF both junit and hamcrest get the test-scope AND hamcrest would  
have

a dependency THEN that dependency is not added to the classpath. That is
still unexpected behavior.


Just add 'test' scope to the hamcrest dependency in that pom. It will
disappear from the classpath. I would expect that to happen. Why should
it manage the version but not the scope?



Because Junit refers to hamcrest classes, so they are required to be able  
to compile.
There is an issue about this, that Maven should never reduce the scope.  
Suppose the user wasn't aware that hamcrest is a runtime requirement of  
JUnit and simply adds it for his own test there as test-scoped dependency  
you will have a surprising effect.
I am of course aware that (currently) a dependency can only have one  
version and one scope. However, I would love to go for a different  
approach: choose one or more scopes and select all their matching  
dependencies + transitive dependencies. Reflecting this to your example  
hamcrest would always be selected as transitive dependency of junit and  
its scope will be ignored.
This matches much better the real world expected behavior no matter what  
the Maven documentation says.


Btw, this looks very close to  
https://issues.apache.org/jira/browse/MNG-6058


Robert



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


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/16/16 um 17:25 schrieb Christian Schulte:
> Am 12/16/16 um 15:21 schrieb Robert Scholte:
>>
>> but this cover the issue we are talking about, because IIUC you are saying  
>> that IF both junit and hamcrest get the test-scope AND hamcrest would have  
>> a dependency THEN that dependency is not added to the classpath. That is  
>> still unexpected behavior.
> 
> Just add 'test' scope to the hamcrest dependency in that pom. 

I am referring to the pom of my email. Just test with 'compile',
'runtime', 'test' and 'provided' scope in the management and repeat that
with the 'optional' flag set to 'true' (mvn -X dependency:tree). For the
'test' and 'provided' scopes it is correct the dependency disappears.
For 'compile' and 'runtime' scopes it is correct the dependency is
resolved in 'runtime' and 'compile' scope. With 'optional' set to 'true'
it is correct the dependency disappears. That's exactly the behaviour
you could observe if all of this would have been declared directly with
the dependency (without using any management). Dependency management in
3.4 makes the managed dependencies resolved the same way they would get
resolved with all of what is done via the management would have been
done directly on the dependencies without any management in use. Compare
that to < 3.4.



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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/16/16 um 15:21 schrieb Robert Scholte:
> 
> but this cover the issue we are talking about, because IIUC you are saying  
> that IF both junit and hamcrest get the test-scope AND hamcrest would have  
> a dependency THEN that dependency is not added to the classpath. That is  
> still unexpected behavior.

Just add 'test' scope to the hamcrest dependency in that pom. It will
disappear from the classpath. I would expect that to happen. Why should
it manage the version but not the scope?


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Robert Scholte]

On Thu, 15 Dec 2016 23:39:50 +0100, Christian Schulte   
wrote:



Am 12/15/16 um 23:28 schrieb Christian Schulte:

different thing. Think about the dependency management as a global
override of everything. That's how the resolver works. That's my


Maven does it that way since 2.0.something. Take a look at this pom:
.
You'll see it declares a dependency on hamcrest-core in version 1.3.
Here is a pom managing that version to 1.1.


http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
  4.0.0
  localhost
  test
  1.0-SNAPSHOT
  jar
  

  
org.hamcrest
hamcrest-core
1.1
  

  
  

  junit
  junit
  4.12

  


Run mvn -X dependency:tree on that pom. You'll see that the version of
the transitive dependency of junit will have been managed to what I put
into that pom. That's exactly what I would expect to happen.

[INFO] localhost:test:jar:1.0-SNAPSHOT
[INFO] \- junit:junit:jar:4.12:compile
[INFO]\- org.hamcrest:hamcrest-core:jar:1.1:compile (version managed
from 1.3)




this is indeed expected behaviour: You are using classes from junit, not  
from hamcrest-core; you want a different version from hamcrest-core, so  
dependencyManagement is the place to specify it.


but this cover the issue we are talking about, because IIUC you are saying  
that IF both junit and hamcrest get the test-scope AND hamcrest would have  
a dependency THEN that dependency is not added to the classpath. That is  
still unexpected behavior.


Robert



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


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/15/16 um 23:28 schrieb Christian Schulte:
> different thing. Think about the dependency management as a global
> override of everything. That's how the resolver works. That's my

Maven does it that way since 2.0.something. Take a look at this pom:
.
You'll see it declares a dependency on hamcrest-core in version 1.3.
Here is a pom managing that version to 1.1.


http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
  4.0.0
  localhost
  test
  1.0-SNAPSHOT
  jar
  

  
org.hamcrest
hamcrest-core
1.1
  

  
  

  junit
  junit
  4.12

  


Run mvn -X dependency:tree on that pom. You'll see that the version of
the transitive dependency of junit will have been managed to what I put
into that pom. That's exactly what I would expect to happen.

[INFO] localhost:test:jar:1.0-SNAPSHOT
[INFO] \- junit:junit:jar:4.12:compile
[INFO]\- org.hamcrest:hamcrest-core:jar:1.1:compile (version managed
from 1.3)



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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/15/16 um 22:31 schrieb Robert Scholte:
> On Thu, 15 Dec 2016 09:40:46 +0100, Christian Schulte   
> wrote:
> 
>> Am 12/15/16 um 09:28 schrieb Robert Scholte:
>>> I think I understand where the confusion is coming from. We must be  
>>> very clear about definitions.
>>> Transitive means adding all indirect dependencies with the compile and  
>>> runtime dependencies.
>>> So the transitive *scope* itself is not transitive, meaning all  
>>> indirect *test*-scoped are not added to the classpath. But IMO a  
>>> test-scoped *dependency* is transitive, all its compile and runtime  
>>> dependencies must be added to the classpath.
>>>
>>
>> That's the way master behaves and it makes sense. What is different is
>> when a transitive dependency is managed to something not transitive.
>> That will disappear from the resolution result. I'd expect that to
>> happen, BTW.
> 
> Well, it is not what I would expect. Any dependency should look in the  
> dependencyManagement of its *parent* (this is also a tricky thing, don't  
> know all the details about the why) and copy the undefined elements from  
> the managed dependency to the direct dependency. I cannot think of any  
> reason why it should suddenly loose its transitive dependencies, because  
> it'll break compilations as we've already seen.

What you describe is what the model builder does. The resolver does a
different thing. Think about the dependency management as a global
override of everything. That's how the resolver works. That's my
expectation of how dependency management should work as well.

POM (I am authoring)
  - dependency management I want to be applied (versions, scopes, etc.)
  - dependencies I need myself

The dependency management in my pom will be applied to all transitive
dependencies overriding what the authors of the POMs of those
dependencies had declared. That's what I expect from the dependency
management as well. It's way more than just a way to not need to add
versions in a multi-module project everywhere.

Regards,
-- 
Christian


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Robert Scholte]

On Thu, 15 Dec 2016 09:40:46 +0100, Christian Schulte   
wrote:



Am 12/15/16 um 09:28 schrieb Robert Scholte:
I think I understand where the confusion is coming from. We must be  
very clear about definitions.
Transitive means adding all indirect dependencies with the compile and  
runtime dependencies.
So the transitive *scope* itself is not transitive, meaning all  
indirect *test*-scoped are not added to the classpath. But IMO a  
test-scoped *dependency* is transitive, all its compile and runtime  
dependencies must be added to the classpath.




That's the way master behaves and it makes sense. What is different is
when a transitive dependency is managed to something not transitive.
That will disappear from the resolution result. I'd expect that to
happen, BTW.


Well, it is not what I would expect. Any dependency should look in the  
dependencyManagement of its *parent* (this is also a tricky thing, don't  
know all the details about the why) and copy the undefined elements from  
the managed dependency to the direct dependency. I cannot think of any  
reason why it should suddenly loose its transitive dependencies, because  
it'll break compilations as we've already seen.


Robert


Means you just must be sure that managing a transitive
dependency from something transitive to something non-transitive will
make that dependency disappear the same way it would disappear when not
managed but declared that way directly.


  

  GID
  AID
  test

  


All GID:AID dependecies are handled the same way they are handled when
'test' had been declared in the model for the dependency
directly. That's consistent. The resolver will apply that 'test' scope
everywhere for GID:AID no matter what has been declared in the model but
did call the 'DependencySelector' without that management applied.


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


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Michael Osipov]

Am 2016-12-15 um 00:39 schrieb Christian Schulte:

Am 12/15/16 um 00:19 schrieb Christian Schulte:

 -ldm,--legacy-dependency-management
Use Maven 2 dependency management behaviour. Can also be activated by
using -Dmaven.legacyDependencyManagement=true.

There are a bunch of issues in JIRA affecting dependency management.
That option could be used to provide a way for users to be able to
switch to the Maven 2 management behaviour. Maybe with this option in
place it would make sense to log warnings whenever this option is used
providing guidance for changing POMs.


We could also release Maven 3.4.0 as Maven 4.0.0 to make things clear
and change the dependency management to whatever behaviour seems to be
the most useful. What we now have on master is just consistent to what
has been documented. The non-transitive scopes start to work correctly.
That means you need to make all transitive dependencies with those
scopes direct dependencies. For 'provided' and 'optional', it makes
sense. If it makes sense for the 'test' scope is questionable. I do not
know the reason for the 'test' scope to be non-transitive. Can someone
clarify that?


I would strongly prefer ALL depenency resolution (code- and/or 
documentation-wise) to be fixed and rebrand to 4.0.0. There is some much 
cleanup that this cannot be a minor, even if you doing the right thing.


All other changes planned for 4.0, like Model 5, etc. can be postponed 
easily to Maven 5.0.


Christian, thank you very much for the in-depth analysis on the issues 
raised over the last couple of weeks on the mailing list. As well as the 
code reviews and fixes.


Michael


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/15/16 um 09:28 schrieb Robert Scholte:
> I think I understand where the confusion is coming from. We must be very 
> clear about definitions. 
> Transitive means adding all indirect dependencies with the compile and 
> runtime dependencies.
> So the transitive *scope* itself is not transitive, meaning all indirect 
> *test*-scoped are not added to the classpath. But IMO a test-scoped 
> *dependency* is transitive, all its compile and runtime dependencies must be 
> added to the classpath.
> 

That's the way master behaves and it makes sense. What is different is
when a transitive dependency is managed to something not transitive.
That will disappear from the resolution result. I'd expect that to
happen, BTW. Means you just must be sure that managing a transitive
dependency from something transitive to something non-transitive will
make that dependency disappear the same way it would disappear when not
managed but declared that way directly.


  

  GID
  AID
  test

  


All GID:AID dependecies are handled the same way they are handled when
'test' had been declared in the model for the dependency
directly. That's consistent. The resolver will apply that 'test' scope
everywhere for GID:AID no matter what has been declared in the model but
did call the 'DependencySelector' without that management applied.


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Robert Scholte]

I think I understand where the confusion is coming from. We must be very clear 
about definitions. 
Transitive means adding all indirect dependencies with the compile and runtime 
dependencies.
So the transitive *scope* itself is not transitive, meaning all indirect 
*test*-scoped are not added to the classpath. But IMO a test-scoped 
*dependency* is transitive, all its compile and runtime dependencies must be 
added to the classpath.

Robert

Verzonden vanaf Samsung Mobile.

 Oorspronkelijk bericht Van: Christian Schulte 
<c...@schulte.it> Datum:15-12-2016  01:29  (GMT+01:00) 
Aan: Maven Developers List <dev@maven.apache.org> 
Onderwerp: Re: maven-wagon git commit: [MRESOLVER-9] 
DefaultDependencyCollector
  does not correctly handle dependency management. 
Am 12/15/16 um 01:15 schrieb Christian Schulte:
> Am 12/14/16 um 23:29 schrieb Michael Osipov:
>> I just hit the same issue with the Maven Clean Plugin: 
>> plexus-container-default is missing on the classpath.
>>
>> I think that Christian does the right thing, either adjusting code to 
>> documentation or the other way around. We just need to agree what is the 
>> right thing and change the problematic spot accordingly.
>>
>> Don't having compile, runtime and test scoped transitive deps of a 
>> direct test dependency doesn't look right to me. There must be some 
>> reason why this decision was made eons ago.
> 
> That could be another bug.
> 
> A -> B (test) -> C (compile)
> 
> When we say "Test scope is not transitive", C should not be resolved as
> well. That's just another inconsistency. We have B in test scope and so
> all transitive dependencies of B implicitly will become test scope. That
> scope is not transitive, so C and all other transitive dependencies of B
> should not be resolved. It's really still inconsistent.

By this I mean: If the scope of C is not managed to 'test', it currently
will be resolved. It really shouldn't, following the 'Test scope is not
transitive'. I read that as: The test scope does not support transitive
dependencies.


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/15/16 um 01:15 schrieb Christian Schulte:
> Am 12/14/16 um 23:29 schrieb Michael Osipov:
>> I just hit the same issue with the Maven Clean Plugin: 
>> plexus-container-default is missing on the classpath.
>>
>> I think that Christian does the right thing, either adjusting code to 
>> documentation or the other way around. We just need to agree what is the 
>> right thing and change the problematic spot accordingly.
>>
>> Don't having compile, runtime and test scoped transitive deps of a 
>> direct test dependency doesn't look right to me. There must be some 
>> reason why this decision was made eons ago.
> 
> That could be another bug.
> 
> A -> B (test) -> C (compile)
> 
> When we say "Test scope is not transitive", C should not be resolved as
> well. That's just another inconsistency. We have B in test scope and so
> all transitive dependencies of B implicitly will become test scope. That
> scope is not transitive, so C and all other transitive dependencies of B
> should not be resolved. It's really still inconsistent.

By this I mean: If the scope of C is not managed to 'test', it currently
will be resolved. It really shouldn't, following the 'Test scope is not
transitive'. I read that as: The test scope does not support transitive
dependencies.


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/14/16 um 23:29 schrieb Michael Osipov:
> I just hit the same issue with the Maven Clean Plugin: 
> plexus-container-default is missing on the classpath.
> 
> I think that Christian does the right thing, either adjusting code to 
> documentation or the other way around. We just need to agree what is the 
> right thing and change the problematic spot accordingly.
> 
> Don't having compile, runtime and test scoped transitive deps of a 
> direct test dependency doesn't look right to me. There must be some 
> reason why this decision was made eons ago.

That could be another bug.

A -> B (test) -> C (compile)

When we say "Test scope is not transitive", C should not be resolved as
well. That's just another inconsistency. We have B in test scope and so
all transitive dependencies of B implicitly will become test scope. That
scope is not transitive, so C and all other transitive dependencies of B
should not be resolved. It's really still inconsistent.

> At the end, I certainly agree with Robert.

If we make "test" scope really consistently non-transitive, we'll soon
all agree that this makes no sense, IMHO.

Regards,
-- 
Christian


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Just an additional information. Maven core and the resolver are not
behaving consistently in that area and also not in the "repository
overriding" area. As you may have noticed, I am just heading for
consistency. I am having a hard time figuring out why the core has not
been updated to reflect changes in the resolver and vice versa. That's
what I did. I have never expected this to lead to such discussions.
Maybe it's just time to reach a consensus on the things in question.
There is no consensus between the core and the resolver in some areas.
Maybe in a lot more areas no-one noticed yet.


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/15/16 um 00:19 schrieb Christian Schulte:
>  -ldm,--legacy-dependency-management
> Use Maven 2 dependency management behaviour. Can also be activated by
> using -Dmaven.legacyDependencyManagement=true.
> 
> There are a bunch of issues in JIRA affecting dependency management.
> That option could be used to provide a way for users to be able to
> switch to the Maven 2 management behaviour. Maybe with this option in
> place it would make sense to log warnings whenever this option is used
> providing guidance for changing POMs.

We could also release Maven 3.4.0 as Maven 4.0.0 to make things clear
and change the dependency management to whatever behaviour seems to be
the most useful. What we now have on master is just consistent to what
has been documented. The non-transitive scopes start to work correctly.
That means you need to make all transitive dependencies with those
scopes direct dependencies. For 'provided' and 'optional', it makes
sense. If it makes sense for the 'test' scope is questionable. I do not
know the reason for the 'test' scope to be non-transitive. Can someone
clarify that?

Regards,
-- 
Christian


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/14/16 um 22:57 schrieb Robert Scholte:
> Digging into this case before the change:
> 
> The 4 related modules ignoring the versions:
> 
> org.apache.maven.wagon:wagon:pom
> {
>  dependencyManagement {
>   dependencies {
>  org.apache.maven.wagon:wagon-provider-test:compile
>   org.codehaus.plexus:plexus-container-default:test,
>   }
>  }
> }
> 
> org.apache.maven.wagon:wagon-provider-test:jar {
>  parent {
>  org.apache.maven.wagon:wagon
>  }
> 
>  dependencies {
> org.codehaus.plexus:plexus-container-default:compile,
>  }
> }
> 
> org.apache.maven.wagon:wagon-providers:pom {
>  parent {
> org.apache.maven.wagon:wagon
>  }
>  dependencies {
>  org.apache.maven.wagon:wagon-provider-test:test
>  }
> }
> 
> org.apache.maven.wagon:wagon-file:jar {
>  parent {
> org.apache.maven.wagon:wagon-providers
>  }
> }
> 
> With the current M3.4.0-SNAPSHOT this fails during test-compile of  
> org.apache.maven.wagon:wagon-file because  
> org.codehaus.plexus:plexus-container-default is not on the classpath

Correct. It's a transitive dependency of 'wagon-provider-test' with
'test' scope.

> btw. wagon-provider-test shows why I don't like managing elements which  
> have a default value: to me it looks weird to (re)set the scope to the  
> default value of compile. But that's a matter of taste, I know...

The 'test' scope from dependency management had been overridden
everywhere to 'compile'. Managing it to 'test' during resolution and
overriding it everywhere to 'compile' (model builder, see A below) makes
no sense.

> 
> So why would we expect org.codehaus.plexus:plexus-container-default on the  
> test-classpath?
> FileWagonTest is only using classes from wagon-provider-test, which is a  
> direct test-scoped dependency (via wagon-providers). Any compile/runtime  
> scoped dependencies from wagon-provider-test should be added to the  
> classpath: that's the responsibility of Maven, not of the user.
> 
> I've removed org.apache.maven.wagon:wagon-provider-test from  
> dependencyManagement and specify its version to the direct dependency and  
> still the build fails for the same reason.
> To me this doesn't make sense, I think there's more to this.
> 
> Anyhow, the original resolution with the so-called bug matches much more  
> the expectations of dependency resolution and current behavior will likely  
> break quite some builds.

I can only comment on what the code is doing. Dependency management is
implemented in two different places.

A) The model builder uses the information from the dependency management
to update elements of dependencies without a value. This has nothing to
do with resolution. The model builder just copies missing elements from
the dependency management to the dependencies when building the
effective model. The model builder will not apply the management
information to dependencies overriding the management values in the
effective model. This appears to be inconsistent to what the resolver does.

B) The dependency management also is passed to the resolver and is used
to manage all dependency elements, regardless of what the model builder
provides (ArtifactDescriptorReader calls the model builder). It has
always been that way. Going into details here means we need to discuss
dependency management as it got introduced in Maven 2.0.x. When Maven
2.0 got released, dependency management had not been implemented.
Someone provided a patch via JIRA making it "work somehow". Browsing to
"Versions" in the MNG project in JIRA shows no 2.x versions anymore. I
cannot look this up. I think that patch got applied and released with
Maven 2.0.6. I am not sure this is the correct version. From there on,
it had always been kept compatible to that patch but has never been
working as intendet. Everyone got used to it that way so anything making
it behave differently will appear to be something unintended.



> Replacing the scope of the dependency from test back its default compile  
> scope whereas the build fails due to missing this test-scoped dependency  
> is weird. I don't have a good story why this new behavior should be  
> better, so IMHO this change must be revisited. If that means we need to  
> adjust documentation, that's fine by me.

As others have suggested, we maybe need to provide a command line option
for this. It's not only the 'test' scope. It's also about 'provided' and
'optional'. Anything non-transitive is affected. There also is the
change from 'ClassicDependencyManager' to 'TransitiveDependencyManager'
and other bugfixes to dependency management. We already have
--legacy-local-repository, so we maybe should just add

 

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Michael Osipov]

Am 2016-12-14 um 22:57 schrieb Robert Scholte:

Digging into this case before the change:

The 4 related modules ignoring the versions:

org.apache.maven.wagon:wagon:pom
{
dependencyManagement {
 dependencies {
org.apache.maven.wagon:wagon-provider-test:compile
org.codehaus.plexus:plexus-container-default:test,
}
}
}

org.apache.maven.wagon:wagon-provider-test:jar {
parent {
org.apache.maven.wagon:wagon
}

dependencies {
   org.codehaus.plexus:plexus-container-default:compile,
}
}

org.apache.maven.wagon:wagon-providers:pom {
parent {
   org.apache.maven.wagon:wagon
}
dependencies {
org.apache.maven.wagon:wagon-provider-test:test
}
}

org.apache.maven.wagon:wagon-file:jar {
parent {
   org.apache.maven.wagon:wagon-providers
}
}

With the current M3.4.0-SNAPSHOT this fails during test-compile of
org.apache.maven.wagon:wagon-file because
org.codehaus.plexus:plexus-container-default is not on the classpath

btw. wagon-provider-test shows why I don't like managing elements which
have a default value: to me it looks weird to (re)set the scope to the
default value of compile. But that's a matter of taste, I know...

So why would we expect org.codehaus.plexus:plexus-container-default on
the test-classpath?
FileWagonTest is only using classes from wagon-provider-test, which is a
direct test-scoped dependency (via wagon-providers). Any compile/runtime
scoped dependencies from wagon-provider-test should be added to the
classpath: that's the responsibility of Maven, not of the user.

I've removed org.apache.maven.wagon:wagon-provider-test from
dependencyManagement and specify its version to the direct dependency
and still the build fails for the same reason.
To me this doesn't make sense, I think there's more to this.

Anyhow, the original resolution with the so-called bug matches much more
the expectations of dependency resolution and current behavior will
likely break quite some builds.
Replacing the scope of the dependency from test back its default compile
scope whereas the build fails due to missing this test-scoped dependency
is weird. I don't have a good story why this new behavior should be
better, so IMHO this change must be revisited. If that means we need to
adjust documentation, that's fine by me.


I just hit the same issue with the Maven Clean Plugin: 
plexus-container-default is missing on the classpath.


I think that Christian does the right thing, either adjusting code to 
documentation or the other way around. We just need to agree what is the 
right thing and change the problematic spot accordingly.


Don't having compile, runtime and test scoped transitive deps of a 
direct test dependency doesn't look right to me. There must be some 
reason why this decision was made eons ago.


At the end, I certainly agree with Robert.

Michael


On Wed, 14 Dec 2016 17:57:47 +0100, Robert Scholte
 wrote:


Hi,

I read the comment but I'm not sure I follow. The original setup is a
widely used pattern: give dependencies which should always have the
test-scope this scope in the dependencyManagement of the parent.
Considering the case below it must be possible to give easymock the
test-scope (I cannot imagine it is used as compile/runtime dependency)

Robert

On Wed, 14 Dec 2016 00:44:56 +0100,  wrote:


Repository: maven-wagon
Updated Branches:
  refs/heads/master 424971d40 -> f244ece2e


[MRESOLVER-9] DefaultDependencyCollector does not correctly handle
dependency management.

o Updated to stop managing the scope of transitive dependencies to
'test'. That scope
  is not transitive. The fix for MRESOLVER-9 updates the resolver to
correctly filter
  out transitive dependencies whose scope got managed to a
non-transitive scope. This
  makes the dependencies disappear from the classpath as of Maven
3.4. Another solution
  would have been to make the dependencies in question direct
dependencies. That way
  the scope could still be managed to 'test' without the dependencies
disappearing
  from the classpaths because they are no longer transitive.


Project: http://git-wip-us.apache.org/repos/asf/maven-wagon/repo
Commit:
http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/f244ece2
Tree: http://git-wip-us.apache.org/repos/asf/maven-wagon/tree/f244ece2
Diff: http://git-wip-us.apache.org/repos/asf/maven-wagon/diff/f244ece2

Branch: refs/heads/master
Commit: f244ece2eee01500e4b1bc334b8dcd35b47f9422
Parents: 424971d
Author: Christian Schulte 
Authored: Wed Dec 14 00:41:02 2016 +0100
Committer: Christian Schulte 
Committed: Wed Dec 14 00:41:02 2016 +0100

--
 pom.xml   | 2 --
 wagon-tcks/wagon-tck-http/pom.xml | 1 -
 2 files changed, 3 deletions(-)
--

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Robert Scholte]

Digging into this case before the change:

The 4 related modules ignoring the versions:

org.apache.maven.wagon:wagon:pom
{
dependencyManagement {
dependencies {
org.apache.maven.wagon:wagon-provider-test:compile
org.codehaus.plexus:plexus-container-default:test,
}
}
}

org.apache.maven.wagon:wagon-provider-test:jar {
parent {
org.apache.maven.wagon:wagon
}

dependencies {
   org.codehaus.plexus:plexus-container-default:compile,
}
}

org.apache.maven.wagon:wagon-providers:pom {
parent {
   org.apache.maven.wagon:wagon
}
dependencies {
org.apache.maven.wagon:wagon-provider-test:test
}
}

org.apache.maven.wagon:wagon-file:jar {
parent {
   org.apache.maven.wagon:wagon-providers
}
}

With the current M3.4.0-SNAPSHOT this fails during test-compile of  
org.apache.maven.wagon:wagon-file because  
org.codehaus.plexus:plexus-container-default is not on the classpath


btw. wagon-provider-test shows why I don't like managing elements which  
have a default value: to me it looks weird to (re)set the scope to the  
default value of compile. But that's a matter of taste, I know...


So why would we expect org.codehaus.plexus:plexus-container-default on the  
test-classpath?
FileWagonTest is only using classes from wagon-provider-test, which is a  
direct test-scoped dependency (via wagon-providers). Any compile/runtime  
scoped dependencies from wagon-provider-test should be added to the  
classpath: that's the responsibility of Maven, not of the user.


I've removed org.apache.maven.wagon:wagon-provider-test from  
dependencyManagement and specify its version to the direct dependency and  
still the build fails for the same reason.

To me this doesn't make sense, I think there's more to this.

Anyhow, the original resolution with the so-called bug matches much more  
the expectations of dependency resolution and current behavior will likely  
break quite some builds.
Replacing the scope of the dependency from test back its default compile  
scope whereas the build fails due to missing this test-scoped dependency  
is weird. I don't have a good story why this new behavior should be  
better, so IMHO this change must be revisited. If that means we need to  
adjust documentation, that's fine by me.


thanks,
Robert


On Wed, 14 Dec 2016 17:57:47 +0100, Robert Scholte   
wrote:



Hi,

I read the comment but I'm not sure I follow. The original setup is a  
widely used pattern: give dependencies which should always have the  
test-scope this scope in the dependencyManagement of the parent.
Considering the case below it must be possible to give easymock the  
test-scope (I cannot imagine it is used as compile/runtime dependency)


Robert

On Wed, 14 Dec 2016 00:44:56 +0100,  wrote:


Repository: maven-wagon
Updated Branches:
  refs/heads/master 424971d40 -> f244ece2e


[MRESOLVER-9] DefaultDependencyCollector does not correctly handle  
dependency management.


o Updated to stop managing the scope of transitive dependencies to  
'test'. That scope
  is not transitive. The fix for MRESOLVER-9 updates the resolver to  
correctly filter
  out transitive dependencies whose scope got managed to a  
non-transitive scope. This
  makes the dependencies disappear from the classpath as of Maven 3.4.  
Another solution
  would have been to make the dependencies in question direct  
dependencies. That way
  the scope could still be managed to 'test' without the dependencies  
disappearing

  from the classpaths because they are no longer transitive.


Project: http://git-wip-us.apache.org/repos/asf/maven-wagon/repo
Commit:  
http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/f244ece2

Tree: http://git-wip-us.apache.org/repos/asf/maven-wagon/tree/f244ece2
Diff: http://git-wip-us.apache.org/repos/asf/maven-wagon/diff/f244ece2

Branch: refs/heads/master
Commit: f244ece2eee01500e4b1bc334b8dcd35b47f9422
Parents: 424971d
Author: Christian Schulte 
Authored: Wed Dec 14 00:41:02 2016 +0100
Committer: Christian Schulte 
Committed: Wed Dec 14 00:41:02 2016 +0100

--
 pom.xml   | 2 --
 wagon-tcks/wagon-tck-http/pom.xml | 1 -
 2 files changed, 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/f244ece2/pom.xml
--
diff --git a/pom.xml b/pom.xml
index fa18390..eefa01a 100644
--- a/pom.xml
+++ b/pom.xml
@@ -282,7 +282,6 @@ under the License.
 org.codehaus.plexus
 plexus-container-default
 1.5.5
-test
   
   
 org.codehaus.plexus
@@ -323,7 +322,6 @@ under the License.
 org.easymock
 easymock
 3.2
-test
   
  

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Michael Osipov]

Am 2016-12-14 um 18:14 schrieb Christian Schulte:

Am 12/14/16 um 17:57 schrieb Robert Scholte:

Hi,

I read the comment but I'm not sure I follow. The original setup is a
widely used pattern: give dependencies which should always have the
test-scope this scope in the dependencyManagement of the parent.
Considering the case below it must be possible to give easymock the
test-scope (I cannot imagine it is used as compile/runtime dependency)


When managing a transitive dependency to 'test' scope, that transitive
dependency must not be resolved the same way it would not be resolved
when set to 'test' scope directly.

A -> B (test) -> C (test)

When resolving A, B and C will not be resolved.

A (manages B and C to test) -> B (managed to test) -> C (managed to test)

When resolving A, B and C will not be resolved. Currently they are
resolved due to a bug. Bugfix makes the 'test' scope consistently
non-transitive. The real issue behind this is: "Why is test scope not
transitive?".


After rereading 
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html, 
it perfectly makes sense what you are saying and the question you are 
asking.


Michael


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Christian Schulte]

Am 12/14/16 um 17:57 schrieb Robert Scholte:
> Hi,
> 
> I read the comment but I'm not sure I follow. The original setup is a  
> widely used pattern: give dependencies which should always have the  
> test-scope this scope in the dependencyManagement of the parent.
> Considering the case below it must be possible to give easymock the  
> test-scope (I cannot imagine it is used as compile/runtime dependency)

When managing a transitive dependency to 'test' scope, that transitive
dependency must not be resolved the same way it would not be resolved
when set to 'test' scope directly.

A -> B (test) -> C (test)

When resolving A, B and C will not be resolved.

A (manages B and C to test) -> B (managed to test) -> C (managed to test)

When resolving A, B and C will not be resolved. Currently they are
resolved due to a bug. Bugfix makes the 'test' scope consistently
non-transitive. The real issue behind this is: "Why is test scope not
transitive?".

Regards,
-- 
Christian


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

Re: maven-wagon git commit: [MRESOLVER-9] DefaultDependencyCollector does not correctly handle dependency management.

[Robert Scholte]

Hi,

I read the comment but I'm not sure I follow. The original setup is a  
widely used pattern: give dependencies which should always have the  
test-scope this scope in the dependencyManagement of the parent.
Considering the case below it must be possible to give easymock the  
test-scope (I cannot imagine it is used as compile/runtime dependency)


Robert

On Wed, 14 Dec 2016 00:44:56 +0100,  wrote:


Repository: maven-wagon
Updated Branches:
  refs/heads/master 424971d40 -> f244ece2e


[MRESOLVER-9] DefaultDependencyCollector does not correctly handle  
dependency management.


o Updated to stop managing the scope of transitive dependencies to  
'test'. That scope
  is not transitive. The fix for MRESOLVER-9 updates the resolver to  
correctly filter
  out transitive dependencies whose scope got managed to a  
non-transitive scope. This
  makes the dependencies disappear from the classpath as of Maven 3.4.  
Another solution
  would have been to make the dependencies in question direct  
dependencies. That way
  the scope could still be managed to 'test' without the dependencies  
disappearing

  from the classpaths because they are no longer transitive.


Project: http://git-wip-us.apache.org/repos/asf/maven-wagon/repo
Commit:  
http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/f244ece2

Tree: http://git-wip-us.apache.org/repos/asf/maven-wagon/tree/f244ece2
Diff: http://git-wip-us.apache.org/repos/asf/maven-wagon/diff/f244ece2

Branch: refs/heads/master
Commit: f244ece2eee01500e4b1bc334b8dcd35b47f9422
Parents: 424971d
Author: Christian Schulte 
Authored: Wed Dec 14 00:41:02 2016 +0100
Committer: Christian Schulte 
Committed: Wed Dec 14 00:41:02 2016 +0100

--
 pom.xml   | 2 --
 wagon-tcks/wagon-tck-http/pom.xml | 1 -
 2 files changed, 3 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/f244ece2/pom.xml
--
diff --git a/pom.xml b/pom.xml
index fa18390..eefa01a 100644
--- a/pom.xml
+++ b/pom.xml
@@ -282,7 +282,6 @@ under the License.
 org.codehaus.plexus
 plexus-container-default
 1.5.5
-test
   
   
 org.codehaus.plexus
@@ -323,7 +322,6 @@ under the License.
 org.easymock
 easymock
 3.2
-test
   
  

http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/f244ece2/wagon-tcks/wagon-tck-http/pom.xml
--
diff --git a/wagon-tcks/wagon-tck-http/pom.xml  
b/wagon-tcks/wagon-tck-http/pom.xml

index 9653ab0..da280f9 100644
--- a/wagon-tcks/wagon-tck-http/pom.xml
+++ b/wagon-tcks/wagon-tck-http/pom.xml
@@ -35,7 +35,6 @@ under the License.
 
   org.codehaus.plexus
   plexus-container-default
-  
   compile
 
 


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