Re: A Maven extension for dependency tracking

[Grzegorz Grzybek <gr...@gmail.com>]

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...@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
>