wt., 24 maj 2022 o 11:17 Tamás Cservenák <ta...@cservenak.net> napisał(a):
> 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... > By "too early" I mean that your dependencyCollected() was already printing the path, while in my case I was only pushing current dependency on top of the stack and full stack was available later in an implementation of org.eclipse.aether.AbstractRepositoryListener However I didn't check if that's simply not the same - I thought that I could have several stack pushed before my implementation of org.eclipse.aether.AbstractRepositoryListener#artifactDownloaded() was called - but I may be wrong. > > > > > > 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? > as above - I was only thinking that there's a difference between these two: - your PR calls dependencyCollected() just after node.getChildren().add() (DF) or context.getParent().getChildren().add() (BF) and prints the reversed dependency path - my extension pushes the dependency (DF only in resolver 1.6.3) and prints the path in org.eclipse.aether.RepositoryListener if these are effectively the same, sorry for confusion ;) > > > > > > 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.... > Yeah... org.eclipse.aether.RepositoryEvent is very "public", so finding a path there would be great. However² I print most of the tracking information not in org.eclipse.aether.RepositoryListener but in overriden org.eclipse.aether.repository.LocalRepositoryManager#find() (because I wanted to know ALL the traces back to the ultimate origin of the dependency - even if it's already downloaded. And org.eclipse.aether.RepositoryEvent can't help here - that's why I needed the static stack... I think that indeed - #176 is something that could be both useful and cheap (defaults to empty method), dependencyCollected() could be invoked with (as in your PR): - context.parents (BF) - args.nodes.nodes (DF) This way my extension would be DF/BF independent and also it could ignore parallel/serial downloader. regards Grzegorz Grzybek > > > Thanks > T >
