On Sat, 02 Jul 2016 16:31:41 +0200, Christian Schulte <c...@schulte.it>
wrote:
Am 07/02/16 um 15:25 schrieb Robert Scholte:
Hi,
It is very likely that a previous version of maven-shared-utils did not
depend on commons-io, which made it required to specify commons-io with
the test-scope for this project.
That's what I assume as well.
With this in mind it seems weird to me to remove commons-io as a direct
test-scoped dependency.
I ment keeping it a direct dependency but updating it's scope to compile
as it no longer is a test-only dependency.
If for some reason we don't need maven-shared-utils anymore the tests of
this project won't build anymore.
And we will notice we need to add that dependency due to build errors.
What I would expect to see for the *runtime* plugin classpath are the
direct dependencies with scopes compile, runtime and system, and all
their
transitive dependencies with the scopes compile, runtime and system.
The interesting thing that will happen here is that when testing it'll
have commons-io:2.5 on its classpath, whereas at runtime it'll have
commons-io:2.4 on its classpath. Based on the docs that can't be right
(every dependency can only have one version and one scope) but I think
it
is.
That's what I find confusing. What makes me think we should do something
about it is that there is no way to notice this other than comparing the
dependency trees manually. If the next upgrade of maven-shared-utils
pulls in 20 depedencies we all have set to test scope noone will notice
this because nothing will warn you about that. The same when transitive
dependencies are removed. The plugin is compiled against commons-io-2.5
because that is the nearer declaration. At runtime, it will use
commons-io-2.4. It's just luck the code does not call a method of 2.5
not available in 2.4. If it would, someone would already have set the
scope to compile. The following is the compile classpath of
maven-resources-plugin. It contains 'commons-io-2.5'. That version comes
from a test dependency. That can't be correct. That test dependency must
not be on the compile classpath, IMHO. I really think that is a bug.
Similar to <https://issues.apache.org/jira/browse/MNG-5988>. Aether does
not destinguish between different classpaths. The test classpath and the
main classpath really should be isolated / independent of each other.
The test dependencies may override dependencies from the compile
classpath during testing but not during compilation. The compile
classpath of maven-resources-plugin should contain commons-io-2.4
because it is a transitive dependency of a compile dependency and the
test classpath should contain commons-io-2.5.
[INFO] Changes detected - recompiling the module!
[DEBUG] Classpath:
[DEBUG]
/home/schulte/Sources/apache.org/plugins/maven-resources-plugin/target/classes
[DEBUG]
/home/schulte/.m2/repository/org/apache/maven/maven-plugin-api/3.0/maven-plugin-api-3.0.jar
[DEBUG]
/home/schulte/.m2/repository/org/sonatype/sisu/sisu-inject-plexus/1.4.2/sisu-inject-plexus-1.4.2.jar
[DEBUG]
/home/schulte/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
[DEBUG]
/home/schulte/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
[DEBUG]
/home/schulte/.m2/repository/org/apache/maven/maven-core/3.0/maven-core-3.0.jar
[DEBUG]
/home/schulte/.m2/repository/org/apache/maven/maven-settings-builder/3.0/maven-settings-builder-3.0.jar
[DEBUG]
/home/schulte/.m2/repository/org/apache/maven/maven-repository-metadata/3.0/maven-repository-metadata-3.0.jar
[DEBUG]
/home/schulte/.m2/repository/org/apache/maven/maven-model-builder/3.0/maven-model-builder-3.0.jar
[DEBUG]
/home/schulte/.m2/repository/org/sonatype/aether/aether-impl/1.7/aether-impl-1.7.jar
[DEBUG]
/home/schulte/.m2/repository/org/sonatype/aether/aether-spi/1.7/aether-spi-1.7.jar
[DEBUG]
/home/schulte/.m2/repository/org/sonatype/aether/aether-api/1.7/aether-api-1.7.jar
[DEBUG]
/home/schulte/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
[DEBUG]
/home/schulte/.m2/repository/org/codehaus/plexus/plexus-classworlds/2.2.3/plexus-classworlds-2.2.3.jar
[DEBUG]
/home/schulte/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.6/plexus-component-annotations-1.6.jar
[DEBUG]
/home/schulte/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[DEBUG]
/home/schulte/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
[DEBUG]
/home/schulte/.m2/repository/org/apache/maven/maven-artifact/3.0/maven-artifact-3.0.jar
[DEBUG]
/home/schulte/.m2/repository/org/apache/maven/maven-settings/3.0/maven-settings-3.0.jar
[DEBUG]
/home/schulte/.m2/repository/org/apache/maven/maven-model/3.0/maven-model-3.0.jar
[DEBUG]
/home/schulte/.m2/repository/org/apache/maven/plugin-tools/maven-plugin-annotations/3.4/maven-plugin-annotations-3.4.jar
[DEBUG]
/home/schulte/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.24/plexus-utils-3.0.24.jar
[DEBUG]
/home/schulte/.m2/repository/org/apache/maven/shared/maven-filtering/3.1.1/maven-filtering-3.1.1.jar
[DEBUG]
/home/schulte/.m2/repository/org/apache/maven/shared/maven-shared-utils/3.0.0/maven-shared-utils-3.0.0.jar
[DEBUG]
/home/schulte/.m2/repository/com/google/code/findbugs/jsr305/2.0.1/jsr305-2.0.1.jar
[DEBUG]
/home/schulte/.m2/repository/org/sonatype/plexus/plexus-build-api/0.0.7/plexus-build-api-0.0.7.jar
[DEBUG]
/home/schulte/.m2/repository/commons-io/commons-io/2.5/commons-io-2.5.jar
[DEBUG]
/home/schulte/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.22/plexus-interpolation-1.22.jar
[DEBUG] Source roots:
[DEBUG]
/home/schulte/Sources/apache.org/plugins/maven-resources-plugin/src/main/java
[DEBUG]
/home/schulte/Sources/apache.org/plugins/maven-resources-plugin/target/generated-sources/plugin
[DEBUG]
/home/schulte/Sources/apache.org/plugins/maven-resources-plugin/target/generated-sources/annotations
Regards,
I agree that this should have been commons-io:2.4, but it matches the
documentation (g:a is unique and nearest wins). I expect that the problem
lies in the way Aether is used.
I assume that first the complete dependency graph is collected no matter
the scope. Next it is resolved so each dependency has the proper scope and
version. And finally there's the scope based filtering.
This order I would like to see it to start with scope filtering. This will
probably be more efficient too, since test-scoped dependencies are
filtered out from the beginning.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
