You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Christian Schulte <cs...@schulte.it> on 2016/07/15 15:56:01 UTC
MNG-4800
Hi,
I have a question regarding the description of MNG-4800. Why should the
scope of x be compile? The part "instead of ... x:compile". Is this
really correct? I see no reason why the scope of x should be updated to
compile. It should be kept runtime because it is a runtime dependency of
c no matter what scope of c is resolved. Can someone explain the reason
for this. Maybe based on a real example. I am asking because I think the
integration test maybe incorrect.
<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/MavenITmng4800NearestWinsVsScopeWideningTest.java;h=9e163202b5aba9d977bce5a64b9557ff45c0ee67;hb=HEAD>
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=tree;f=core-it-suite/src/test/resources/mng-4800;h=d254e7dd63d7f99bc15ad0a1fca3e146b964f8b7;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-4800
Posted by Robert Scholte <rf...@apache.org>.
On Sat, 16 Jul 2016 20:15:16 +0200, Christian Schulte <cs...@schulte.it>
wrote:
> Am 16.07.2016 um 15:40 schrieb Robert Scholte:
>> I understand that every element has an original scope, but I wonder if
>> it
>> is useful in the tree. I'd say based on the scope(s) you get a certain
>> tree, where scopes don't matter anymore.
>> This would probably also solve the test-scoped issue in the other
>> thread.
>>
>> project () // no scope filtering
>> +- a
>> | \- c:1
>> | \- x
>> \- b
>>
>> project (runtime,compile)
>> +- a
>> | \- c:1
>> | \- x
>> \- b
>>
>> project (runtime)
>> +- a
>> | \- c:1
>> | \- x
>>
>> project (compile)
>> +- b
>> \- c:2
>> \- y
>>
>
> So you would also say that the nodes should be choosen based on the
> context of the root node? If you depend on something in compile scope,
> that scope should have priority when selecting nodes no matter the depth
> of conflicting nodes. Same for the other scopes. If you depend on
> something in test scope, that scope should have priority when selecting
> nodes no matter the depth of conflicting nodes etc. This is what I am
> working on locally. Still work in progess. Still need to carefully
> review all those ITs and also implement version ranges to have something
> to talk about.
>
> Regards,
Quite close. I don't think there's something like priority for scopes. The
first thing that should be done is select all dependencies based on the
specified scopes. So e.g. maven-compiler-plugin:compile would specify the
scopes compile, provided and system. After filtering out all unnecessary
dependencies the nearest-rule kicks in again.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-4800
Posted by Christian Schulte <cs...@schulte.it>.
Am 16.07.2016 um 15:40 schrieb Robert Scholte:
> I understand that every element has an original scope, but I wonder if it
> is useful in the tree. I'd say based on the scope(s) you get a certain
> tree, where scopes don't matter anymore.
> This would probably also solve the test-scoped issue in the other thread.
>
> project () // no scope filtering
> +- a
> | \- c:1
> | \- x
> \- b
>
> project (runtime,compile)
> +- a
> | \- c:1
> | \- x
> \- b
>
> project (runtime)
> +- a
> | \- c:1
> | \- x
>
> project (compile)
> +- b
> \- c:2
> \- y
>
So you would also say that the nodes should be choosen based on the
context of the root node? If you depend on something in compile scope,
that scope should have priority when selecting nodes no matter the depth
of conflicting nodes. Same for the other scopes. If you depend on
something in test scope, that scope should have priority when selecting
nodes no matter the depth of conflicting nodes etc. This is what I am
working on locally. Still work in progess. Still need to carefully
review all those ITs and also implement version ranges to have something
to talk about.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-4800
Posted by Robert Scholte <rf...@apache.org>.
On Fri, 15 Jul 2016 20:08:22 +0200, Christian Schulte <cs...@schulte.it>
wrote:
> Am 07/15/16 um 19:52 schrieb Robert Scholte:
>> I think you're right. The main issue here is c:1 is the first closest
>> one,
>> but since the c:2 has compile scope, so should c:1. However, that
>> doesn't
>> change the scope for transitive dependencies of c:1
>>
>> A bit off-topic: Where is this scope order specified? In case of custom
>> scopes we probably need to do something with scope-order too.
>
> I have no idea. All I have found is the source code [1]. If someone
> knows, please help. We have a 'JavaScopeSelector' applying a
> prioritization based on something "widest scope" which has nothing to do
> with anything nearest wins, a 'NearestVersionSelector' which does not
> always select the nearest version and has nothing to do with anything
> nearest wins, a 'SimpleOptionalitySelector' which has nothing to do with
> nearest wins. We have always said that Maven is applying a "nearest
> wins" strategy when resolving conflicts. That only applies to version
> hints. Hard version requirements, scopes, optionality are implemented
> very differently. I do not even quite understand why the scope of 'c'
> needs to be updated to compile. If we say nearest wins, then the scope
> of 'c' should be runtime. So that users need to pull up dependencies in
> question manually (to get correct POM files). There is quite a lot going
> on during conflict resolution which has nothing to do with anything
> nearest wins and I am trying to understand where that logic comes from.
>
> [1]
> <https://git-wip-us.apache.org/repos/asf?p=maven-aether.git;a=tree;f=aether-util/src/main/java/org/eclipse/aether/util/graph/transformer;h=f7f02c5e6a8544da917217d036339617daa0c636;hb=HEAD>
>
> Regards,
I understand that every element has an original scope, but I wonder if it
is useful in the tree. I'd say based on the scope(s) you get a certain
tree, where scopes don't matter anymore.
This would probably also solve the test-scoped issue in the other thread.
project () // no scope filtering
+- a
| \- c:1
| \- x
\- b
project (runtime,compile)
+- a
| \- c:1
| \- x
\- b
project (runtime)
+- a
| \- c:1
| \- x
project (compile)
+- b
\- c:2
\- y
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-4800
Posted by Christian Schulte <cs...@schulte.it>.
Am 07/15/16 um 19:52 schrieb Robert Scholte:
> I think you're right. The main issue here is c:1 is the first closest one,
> but since the c:2 has compile scope, so should c:1. However, that doesn't
> change the scope for transitive dependencies of c:1
>
> A bit off-topic: Where is this scope order specified? In case of custom
> scopes we probably need to do something with scope-order too.
I have no idea. All I have found is the source code [1]. If someone
knows, please help. We have a 'JavaScopeSelector' applying a
prioritization based on something "widest scope" which has nothing to do
with anything nearest wins, a 'NearestVersionSelector' which does not
always select the nearest version and has nothing to do with anything
nearest wins, a 'SimpleOptionalitySelector' which has nothing to do with
nearest wins. We have always said that Maven is applying a "nearest
wins" strategy when resolving conflicts. That only applies to version
hints. Hard version requirements, scopes, optionality are implemented
very differently. I do not even quite understand why the scope of 'c'
needs to be updated to compile. If we say nearest wins, then the scope
of 'c' should be runtime. So that users need to pull up dependencies in
question manually (to get correct POM files). There is quite a lot going
on during conflict resolution which has nothing to do with anything
nearest wins and I am trying to understand where that logic comes from.
[1]
<https://git-wip-us.apache.org/repos/asf?p=maven-aether.git;a=tree;f=aether-util/src/main/java/org/eclipse/aether/util/graph/transformer;h=f7f02c5e6a8544da917217d036339617daa0c636;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-4800
Posted by Robert Scholte <rf...@apache.org>.
I think you're right. The main issue here is c:1 is the first closest one,
but since the c:2 has compile scope, so should c:1. However, that doesn't
change the scope for transitive dependencies of c:1
A bit off-topic: Where is this scope order specified? In case of custom
scopes we probably need to do something with scope-order too.
Robert
On Fri, 15 Jul 2016 17:56:01 +0200, Christian Schulte <cs...@schulte.it>
wrote:
> Hi,
>
> I have a question regarding the description of MNG-4800. Why should the
> scope of x be compile? The part "instead of ... x:compile". Is this
> really correct? I see no reason why the scope of x should be updated to
> compile. It should be kept runtime because it is a runtime dependency of
> c no matter what scope of c is resolved. Can someone explain the reason
> for this. Maybe based on a real example. I am asking because I think the
> integration test maybe incorrect.
>
> <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/MavenITmng4800NearestWinsVsScopeWideningTest.java;h=9e163202b5aba9d977bce5a64b9557ff45c0ee67;hb=HEAD>
>
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=tree;f=core-it-suite/src/test/resources/mng-4800;h=d254e7dd63d7f99bc15ad0a1fca3e146b964f8b7;hb=HEAD>
>
> Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org