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 napisał(a):
> Howdy, inline, also PR updated, simplified, and added a "demo" listener
> that does exactly what
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
wrote:
> Hello and thank you very much for your time ;)
>
> This looks exactly how I imagined it ;) - that the path is reachable via
> the
Hello and thank you very much for your time ;)
wt., 24 maj 2022 o 15:54 Tamás Cservenák 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
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
wt., 24 maj 2022 o 11:17 Tamás Cservenák 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
> >
> >
>
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
Hello
I've finally found some time to check your PR#176 Tamás... Here are my
comments and answers (also to previous messages).
https://github.com/apache/maven-resolver/pull/176
>
> So here is some implementation "demo" (that could be made into extension
> point), as explained in Draft PR
Hello!
Thanks for your comments and PR - I needed to switch to different tasks,
but soon (next week?) I'm going to spend more time on it. I yet have to get
a feeling of the graph/stack that could be passed around.
And check these DF/BF dependency collectors (as I didn't see them in
resolver
Howdy,
https://github.com/apache/maven-resolver/pull/176
So here is some implementation "demo" (that could be made into extension
point), as explained in Draft PR description.
BUT, also as written in PR, am getting a feeling that doing this is
"dangerous", and a simple callback with whole
Howdy,
just a few short answers:
- 1st: Personally, from a Resolver perspective, I'd just provide an API
(basically the author extending resolver should implement) and make it
simple to "click in" (Sisu component discovery).
- 2nd: resolver IMHO should not provide any out of the box component
Thank you Tamás for checking my experiment
I'm just finishing my work before tomorrow's national holiday, but will
read your information more carefully soon.
Whether it's DFS or BFS, as long as there's tracking from initial to
ultimate dependency, it's enough. DFS sounds more "natural" here
What I missed to mention: in my case the trees in the gist are about
"resolving maven-core 3.5.8", but I guess you figured it out from the
tree
T
On Mon, May 2, 2022 at 3:55 PM Tamás Cservenák wrote:
> Howdy,
>
> I did some experiment, that (partially re-using your code to dump the rev
>
Howdy,
I did some experiment, that (partially re-using your code to dump the rev
tree) produces this output:
https://gist.github.com/cstamas/598a3266f943984442c00df30520294f
(note: 1.8.0 resolver has two collector implementations: original
Depth-First and new Breadth-First called DF and BF
Howdy,
This is very cool, I was actually tinkering on very similar issues in
resolver coming from totally different angles.
And yes, the resolver collector is not quite "extension" friendly, but we
will make it right.
Just FYI, that in the latest resolver (1.8.0) there are actually two
Hello
TL;DR: https://github.com/grgrzybek/tracking-maven-extension
I'd like to share some proof of concept I made. It all started with a
question "why I'm getting log4j:log4j:1.2.12" in my local Maven repository
when building trivial project with fresh local repo?
I knew it's possible to `grep
15 matches
Mail list logo
