You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Michael Osipov <19...@gmx.net> on 2016/12/19 14:56:45 UTC
Scope promotion of managed dependencies in current Maven master
Hi folks,
I just tried a fresh Maven master (7d1d8ac0c14bdea6c92356436bfc6f8548cbae8b; 2016-12-19T15:22:22+01:00)
on an in-house project.
My project's parent POM states in depMgmt:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${slf4j.version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>${slf4j.version}</version>
<scope>runtime</scope>
</dependency>
nothing special so far, a WAR module dependends on net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
which has slf4j-simple in *test* scope. mvn dependency:tree with 3.3.9 properly gives me:
[DEBUG] net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
Doing this with master gives me:
[DEBUG] net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
[DEBUG] org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from test by com.company.project:project-parent:0.11-SNAPSHOT)
My questions are:
1. Is this another fix in master where I relied on an erratic behavior in core previously?
2. Should depMgmthave influence on transitive deps or direct only?
I cannot really say what's right or wrong but now I have two SLF4J bindings on my WAR classpath:
SLF4J Simple and Logback, now that is obviously wrong!
Any thoughts?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Scope promotion of managed dependencies in current Maven master
Posted by Guillaume Boué <gb...@apache.org>.
Hi Michael,
I can reproduce that behaviour as well. In the current 3.4.0, a
dependency management that declares a dependency with scope runtime will
manage a transitive dependency of scope test. A reproducer is
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>1.7.21</version>
<scope>runtime</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>test</groupId>
<artifactId>test</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
And having in the POM of test:
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>1.7.21</version>
<scope>test</scope>
</dependency>
</dependencies>
This doesn't feel right to me: dependencies of scope test are not
transitive, so the test scoped slf4j-simple shouldn't be considered
during dependency resolution. I wouldn't also expect the
dependencyManagement to change the scope of the inherited slf4j-simple
(if it were to be inherited), since there are definite rules about which
scope a transitive dependency should have depending on the scope of the
declared dependency (summarized in the table here
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope).
Guillaume
Le 19/12/2016 � 15:56, Michael Osipov a �crit :
> Hi folks,
>
> I just tried a fresh Maven master (7d1d8ac0c14bdea6c92356436bfc6f8548cbae8b; 2016-12-19T15:22:22+01:00)
> on an in-house project.
>
> My project's parent POM states in depMgmt:
>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-api</artifactId>
> <version>${slf4j.version}</version>
> </dependency>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>jcl-over-slf4j</artifactId>
> <version>${slf4j.version}</version>
> <scope>runtime</scope>
> </dependency>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-simple</artifactId>
> <version>${slf4j.version}</version>
> <scope>runtime</scope>
> </dependency>
>
> nothing special so far, a WAR module dependends on net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
> which has slf4j-simple in *test* scope. mvn dependency:tree with 3.3.9 properly gives me:
>
> [DEBUG] net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
>
> Doing this with master gives me:
>
> [DEBUG] net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
> [DEBUG] org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from test by com.company.project:project-parent:0.11-SNAPSHOT)
>
> My questions are:
> 1. Is this another fix in master where I relied on an erratic behavior in core previously?
> 2. Should depMgmthave influence on transitive deps or direct only?
>
> I cannot really say what's right or wrong but now I have two SLF4J bindings on my WAR classpath:
> SLF4J Simple and Logback, now that is obviously wrong!
>
> Any thoughts?
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
L'absence de virus dans ce courrier �lectronique a �t� v�rifi�e par le logiciel antivirus Avast.
https://www.avast.com/antivirus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Scope promotion of managed dependencies in current Maven master
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/20/16 um 10:28 schrieb Michael Osipov:
>> Am 12/19/16 um 15:56 schrieb Michael Osipov:
>>> [DEBUG] net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
>>> [DEBUG] org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from test by com.company.project:project-parent:0.11-SNAPSHOT)
>>
>> <https://issues.apache.org/jira/browse/MRESOLVER-9>
>>
>> That's what the resolver does. It uses the management as a global
>> override for transitive dependencies. It's correct this will get managed
>> to 'runtime'. That's what you have in your management.
>
> I am horribly afraid that you are right, our documentation says:
> "b is defined in B's parent's dependency management section and since dependency management
> takes precedence over dependency mediation for transitive dependencies, version
> 1.0 will be selected should it be referenced in a or c's pom. b will also have compile scope."
>
Looking at my personal POMs, I really never manage any scopes. This may
be due to Netbeans providing hints whenever you override something from
management. There is not a single multi-module project here where the
scope from the management would not have to be overridden in at least
one module of the reactor. I am not sure the core model builder really
is doing the right thing. If it would manage (override) things the same
way the resolver does, things like this would not happen. Your 'test'
dependency would always have been 'runtime', no matter what. That would
have made you remove the scope from management because the scope is not
the same across all modules of that reactor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re: Scope promotion of managed dependencies in current Maven
master
Posted by Michael Osipov <19...@gmx.net>.
> Am 12/19/16 um 15:56 schrieb Michael Osipov:
> > [DEBUG] net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
> > [DEBUG] org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from test by com.company.project:project-parent:0.11-SNAPSHOT)
>
> <https://issues.apache.org/jira/browse/MRESOLVER-9>
>
> That's what the resolver does. It uses the management as a global
> override for transitive dependencies. It's correct this will get managed
> to 'runtime'. That's what you have in your management.
I am horribly afraid that you are right, our documentation says:
"b is defined in B's parent's dependency management section and since dependency management
takes precedence over dependency mediation for transitive dependencies, version
1.0 will be selected should it be referenced in a or c's pom. b will also have compile scope."
> > My questions are:
> > 1. Is this another fix in master where I relied on an erratic behavior in core previously?
> > 2. Should depMgmthave influence on transitive deps or direct only?
>
> Direct dependencies (those being declared in the POM) are handled by the
> core (model builder), transitive dependencies are handled by the
> resolver. It has always been that way. This is what has changed:
>
> <https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blobdiff;f=aether-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultDependencyCollector.java;h=62a8ff2a0ab8fd99576777446266ca588bc0fe40;hp=f1fcbf258de04b698e0ce23ca91e6827b5e6a47d;hb=1ee92862c67ec98564c4d8be1207355960f1dd5d;hpb=11a061b66fd15b8c3584f48afa69955d9392861e>
Thanks for that!
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Scope promotion of managed dependencies in current Maven master
Posted by Christian Schulte <cs...@schulte.it>.
Am 12/19/16 um 15:56 schrieb Michael Osipov:
> [DEBUG] net.sf.michael-o.dirctxsrc:dircontextsource:jar:1.3:compile
> [DEBUG] org.slf4j:slf4j-simple:jar:1.7.21:runtime (scope managed from test by com.company.project:project-parent:0.11-SNAPSHOT)
<https://issues.apache.org/jira/browse/MRESOLVER-9>
That's what the resolver does. It uses the management as a global
override for transitive dependencies. It's correct this will get managed
to 'runtime'. That's what you have in your management.
> My questions are:
> 1. Is this another fix in master where I relied on an erratic behavior in core previously?
> 2. Should depMgmthave influence on transitive deps or direct only?
Direct dependencies (those being declared in the POM) are handled by the
core (model builder), transitive dependencies are handled by the
resolver. It has always been that way. This is what has changed:
<https://git-wip-us.apache.org/repos/asf?p=maven-resolver.git;a=blobdiff;f=aether-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultDependencyCollector.java;h=62a8ff2a0ab8fd99576777446266ca588bc0fe40;hp=f1fcbf258de04b698e0ce23ca91e6827b5e6a47d;hb=1ee92862c67ec98564c4d8be1207355960f1dd5d;hpb=11a061b66fd15b8c3584f48afa69955d9392861e>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org