Am 12/24/16 um 17:03 schrieb Robert Scholte: > With this commit commons-io gets the default scope. > Suppose PMD drops commons-io, then there's no reason that this dependency > has the compile scope. > Assuming the unittests are using commons-io it makes sense that it has the > test-scope.
Putting that dependency into that POM makes it the nearest declaration during resolving dependencies. When using test scope, that will disappear from the plugin's runtime (application) classpath and that will make the plugin blow up. It's a test dependency of the plugin and also a transitive compile dependency of some compile dependency of the plugin. > Be aware that users can overwrite dependencies of plugins in their pom.xml > Developers can only know about the dependencies for their src/main/java > and src/test/java code, and cannot do any assumptions about transitive > dependencies due to all the override mechanisms in Maven. If the ITs would have failed right from the start, the person adding those test dependencies would have done the right thing back then. > It may be clear that I don't like these changes. I haven't expected anything else :-) What has led to that bugfix in the resolver was something completely different. I hadn't expected such an impact back then. From what I can tell so far, it's really uncovering bugs in the POMs. The "one tree per project" logic is what makes this look strange. Someone adds a test dependency to a project to express that dependency to be needed during testing although that same dependency also is needed in the application/main classpath. Looks like this will be handled way more intelligent in model version 5.0.0, from what I can tell. Right now we have that "nearest wins" strategy in model version 4.0.0. If the nearest node happens to be in test scope, that nearest node will not be part of the main/application/project/you name it classpath. I would want the test classpath used to run all unit tests to match what is used at runtime. For this, plugins need to be resolved the same way as projects. Taking a closer look at this, Hervé raised another very valid point. The resolver still throws away non-transitive nodes the next level in the hierarchy during collecting dependencies. Following that "there should never be a difference between project or dependency resolution" statement of Hervé, the resolver should really never cut off any nodes during collecting dependencies and should pass all of what is there to the conflict resolver. Implementing that looks easy (one line of code to change). I doubt the conflict resolver will handle that new "input tree" correctly immediately. Will give it a try locally, though. Regards, -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
