Thanks Tamas. I'm looking at https://github.com/apache/maven-resolver/pull/182 today (and apologies for delay - other tasks...). See inline.
pt., 27 maj 2022 o 21:19 Tamás Cservenák <ta...@cservenak.net> napisał(a): > Howdy, inline, also PR updated, simplified, and added a "demo" listener > that does exactly what you wanted. > > On Fri, May 27, 2022 at 8:24 AM Grzegorz Grzybek <gr.grzy...@gmail.com> > wrote: > > > Hello and thank you very much for your time ;) > > > > 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. > > > > > Yes, now you can do everything as a listener. There is a "demo" added that > does exactly what you want. > Still, the warning stands: listener "steals" time from collection, > collecting is "hot", so be quick! :) > But now we are thread-safe as well, so "parallel pom" download will work as > well. > (there is one thing I need to fix: for this safety I need to COPY the path > list, as once multithreaded, that list will change!!!) > So in ideal situation (no listener registered), the only cost would be the copy. I'll check collectStepTrace() impact by building some of my projects and I'll let you know. > > > > > > 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? > > > > I was talking about another extension point to be added, which is not > there. > But now I am unsure if it is needed or not... > ok, so no full tree, but just a path collected in RequestTrace - that's what I needed ;) > > > > > > 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 ;) > > > Yes, event is called a bit more: for every artifact being resolved, that > means that is called > for POMs (when artifactDescriptorRequest is run in collector), but that one > request may trigger SEVERAL > events, like for the POM, then for it's parent POM, then for parent parent > POM etc. This is model builder, that > is building the effective POM for a given artifact, and in case it has a > parent POM, hence it needs to be resolved > as well. > And THAT was exactly the reason I wanted to track everything. Yes - I wanted parent poms, grandparent poms, parents of boms, etc... > > Hence, there is that little "trick" in place that ensures that tree is > written only once, see the demo listener. > It could be improved even more (like in the case of mvnd, where you may > have several ongoing sessions at once). > Thanks - I promise to check PR#182 this week. regards Grzegorz Grzybek > > HTH > Tamas >
