Howdy, inline only the "interesting" part:
So, after playing a bit with 1.8.0[.1] of the BF/DF resolvers and your #176 > PR, I see that example > > org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate#dependencyCollected() > extension point you've introduced is a bit too early for my use case... > It's invoked during dependency collection, but I think it'd be better to > simply use "full path" when there's actual download (or resolution from > local repository). > This part I don't quite get: "too early"? What do you mean here? As events you use are fired "even before" as I see... > > My whole need to extend resolver was to collect the path from initial to > final dependency, so the stack is available when it's needed. > Isn't the PR doing that? Or did I miss something? > > Initially I thought that org.eclipse.aether.RequestTrace should be the > thing I could use to get current dependency path, but I found it's not > possible. > Yes, my hopes were geared toward RequestTrace as well, as it could represent a tree just fine, but.... > > Maybe your DependencyCollectorDelegate#dependencyCollected() could simply > "expose" the List<DependencyNode> path somewhere? Maybe in Maven session? > as attribute? > In a moment parallel collection comes into picture ( https://github.com/apache/maven-resolver/pull/178) this will be not enough, as there is one session but multiple threads are working on it. Hence, I agree that "hooking" onto existing events would be the best, but, sadly they are quite disconnected from collectors, hence, it is hard to "couple" them in the right manner.... Cleanest would be if the event would carry its own copy of path.... Thanks T
