-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MNG-7619] Reverse Dependency Tree #900
[MNG-7619] Reverse Dependency Tree #900
Conversation
Adds Maven feature that is able to explain why an artifact is present in local repository. Usable for diagnosing resolution issues. --- https://issues.apache.org/jira/browse/MNG-7619
Excercise: build this PR (will produce Maven 3.9.0-SNAPSHOT distro), then use same distro to build itself (or just maven.3.9.x, does not matter) using these:
(rat is dumb to inspect "local" where local repository is and fail, so we skip it). Q1: why is maven-core 2.2.1 in local repo?
Q2: how many commons-codec we used and why?
|
maven-core/src/main/java/org/apache/maven/internal/aether/ReverseTreeRepositoryListener.java
Outdated
Show resolved
Hide resolved
maven-core/src/main/java/org/apache/maven/internal/aether/ReverseTreeRepositoryListener.java
Show resolved
Hide resolved
Note: this is based on by @grgrzybek proposal and reuses some code he provided. See apache/maven-resolver#182 |
Can we leave out these empty parens: |
Thats org.eclipse.aether.graph.Dependency#toString, we could fix it, but given this is "advanced" feature, I don't think is something would block this? |
Agree, we need to spin off the issue there. Here, no change is required. |
Not sure if this was already mentioned, but instead of "bake this in" would it not be better to have a way for (core-)plugins to hook in a I also wonder if it is even required to record the data at all, should it not be sufficient to first load the pom(s), then generate a list of used plugins and then resolve their dependencies and then do something similar to |
@laeubi while I agree with ideas you wrote, I am still for this PR to go in, here is why: Also, none of these prevents anything of those things you wrote, this is totally orthogonal. I personally see this like |
.getFile() | ||
.getPath() | ||
.startsWith(event.getSession().getLocalRepository().getBasedir().getPath())) { | ||
return; // reactor artifact |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this condition be extracted to method IDK, isReactorArtifact(event)
?
The comment then removed?
The method tested?
return; // reactor artifact | ||
} | ||
RequestTrace trace = event.getTrace(); | ||
CollectStepData collectStepTrace = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this variable be moved one line up, and the loop then extracted to (tested) class method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Class method (static) would need no instance for test. Like it doesn't to do its job.
Um, unsure why GH says "removed request" from @pzygielo , I actually asked both @michael-o and @pzygielo for repeated review... |
Adds Maven feature that is able to explain why an artifact is present in local repository. Usable for diagnosing resolution issues. In local repository, for each artifact it records `.tracking` folder, containing farthest artifact that got to this artifact, and the list of graph nodes that lead to it. Note: this is based on by @grgrzybek proposal and reuses some code he provided. See apache/maven-resolver#182 Forward-port of: apache#900 --- https://issues.apache.org/jira/browse/MNG-7619
Adds Maven feature that is able to explain why an artifact is present in local repository.
Usable for diagnosing resolution issues.
In local repository, for each artifact it records
.tracking
folder, containing farthest artifact that got to this artifact, and the list of graph nodes that lead to it.Note: this is based on by @grgrzybek proposal and reuses some code he provided. See apache/maven-resolver#182
https://issues.apache.org/jira/browse/MNG-7619