cstamas commented on PR #170: URL: https://github.com/apache/maven-compiler-plugin/pull/170#issuecomment-1401478634
One big fat warning about this approach, or in general for "resolving": if you look at old code carefully, you will see it did `new CollectRequest( new Dependency( artifact, JavaScopes.RUNTIME ), project.getRemoteProjectRepositories() )` (pay attention to `CollectRequest` ctor), it used current artifact _as root_ and resolved it's dependencies. What new code does is pushing all the enlisted artifacts as "direct dependencies" of some (imaginary) root (again, according to Javadoc of changed ctor for `CollectRequest`). This has slightly different meaning and semantics, especially with optional dependencies, see https://github.com/apache/maven-resolver/blob/master/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/selector/OptionalDependencySelector.java#L52-L56 The change in semantics comes from fact that new code will "push" all things +1 regarding depth (as they each are not root anymore, but are direct siblings on some imaginary root). In this very case (compiler annotation processors) this is completely OK, but when you try to "mimic" what Maven does not result in same outcome, for example when Maven resolves a plugin, it is used as root, and hence, this approach in this PR _cannot_ be applied to bootstrap IT here (see https://github.com/apache/maven-integration-testing/pull/236 and example mentioned in it). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
