Hello and thank you very much for your time ;)
wt., 24 maj 2022 o 15:54 Tamás Cservenák <ta...@cservenak.net> napisał(a): > 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) > This looks exactly how I imagined it ;) - that the path is reachable via the RequestTrace! Doing everything in the RepositoryListener (correct me if I'm wrong, but artifactResolved() is called both after remote access and when the artifact is found in local repo?) looks very clean, because it's natural to register such listeners - much more natural than extending some crucial classes from the resolver. > > 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?) > I remember you mentioned this "end graph", but I didn't find a place (hook, listener) where I can get it - could you please point me to the class? > > 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.... > I think artifactResolved() callback was called not only for POMs... and all the changes made to the collector were supposed to prepare the dependency path, so I didn't see a problem here. But you're the expert ;) kind regards Grzegorz Grzybek > > > 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 > > > > > >
