Howdy, take a look at this: https://github.com/apache/maven-resolver/pull/182 (demos are "mutilated" just to run them and observe output, changes there are unrelated)
But still, I am on edge: I still don't see why all this is "better", then just observe the collection end graph (having all, and then just write out reverse dep trees then?) Also, this is an "early" phase, the collection, hence only POMs are being downloaded. And the fact POM is downloaded (collected), does NOT mean JAR will be downloaded (resolved) as well.... Thanks T On Tue, May 24, 2022 at 12:40 PM Grzegorz Grzybek <gr.grzy...@gmail.com> wrote: > 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 > > >
