-
Notifications
You must be signed in to change notification settings - Fork 33
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
[MPH-183] Effective POM path to source #37
base: master
Are you sure you want to change the base?
[MPH-183] Effective POM path to source #37
Conversation
2333232
to
4391032
Compare
src/main/java/org/apache/maven/plugins/help/EffectivePomMojo.java
Outdated
Show resolved
Hide resolved
src/main/java/org/apache/maven/plugins/help/EffectivePomMojo.java
Outdated
Show resolved
Hide resolved
4391032
to
307fd9a
Compare
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.
Looks good to me. Happy to see the unhappy paths (e.g. running older Maven versions) are handled gracefully.
Let's wait for a build of Maven Core that adds this feature (apache/maven#603) so we can test-drive this feature once more before merging.
307fd9a
to
e467844
Compare
5771163
to
3073624
Compare
import org.codehaus.plexus.util.StringUtils; | ||
|
||
/** | ||
* Maven 3.x-based implementation of {@link InputLocation.StringFormatter}. |
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.
it's not Maven 3, it"s "without import tracking", as I hope we'll have import tracking for Maven 3 too
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.
Agreed, we should probably change the name of the class and edit the JDocs. We would like to backport it to Maven 3, but initially want to make it work for Maven 4 first without breaking other versions.
try { | ||
InputLocation result = (InputLocation) getImportedFromMethod.invoke(location); | ||
|
||
if (result == null && project != 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.
I don't get why we do all this: if the current location is not the result of an import, why are we trying to do something?
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.
When there is an importedFrom on the current dependency we can simply return the result, if there is not an importedFrom on the current dependency we try to find a match in the dependencies of dependencyManagement
InputLocation result = (InputLocation) getImportedFromMethod.invoke(location); | ||
|
||
if (result == null && project != null) { | ||
for (Dependency dependency : project.getDependencyManagement().getDependencies()) { |
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.
MNG-7344 is not supposed to be limited to dependencyManagement import, but be able to work with imports done for example by Tiles Maven Plugin. Then iterating only on dependencyManagement is suspect
notice that this opens again the question of what is the purpose of trying to do something if there war no importFrom in location
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.
I've no experience with the maven tiles plugin. If this results in the same model (which I assume it does) it probably would still work, we would have to test this though.
* Implementation of {@link InputLocation.StringFormatter}. Enhances the default implementation with support for | ||
* following "references" (caused by e.g. dependency management imports). | ||
*/ | ||
public class ImportedFromLocationFormatter extends InputLocation.StringFormatter { |
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.
if this class was only working on import tracking, and be injected in DefaultLocationFormatter if proper InputLocation API was found, this would IMHO clarify the purpose of this addition, that keeps using the initial location tracking
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.
We thought it would make sense to separate the actual display logic from the logic on whether or not to use the correct formatter. We could change that but it would bundle more logic in to 1 bigger class?
|
||
while (importedFrom != null | ||
&& !source.toString().equals(importedFrom.getSource().toString())) { | ||
p.append(" from ").append(importedFrom.getSource().getModelId()); |
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.
we also need the line, to know where the import has been done: there may be multiple ones in a source
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.
If I understand your comment correctly, we print the line in the return statement (line 67).
If we have a project like:
bom1 -> dependency x (line 12)
^
|
bom2 -> import bom1
^
|
project -> import bom2
The output of the effective pom of this project's dependency shows bom1, line 12 from bom2
Marked ready for review on behalf of @juulhobert. |
3f989f6
to
26ba8ea
Compare
The goal of MPH-183 is to print via which BOM(s) a dependency got in the effective POM.
Related MNG-7344 PR that introduces the necessary changes in the model: apache/maven#603
Method for retrieving the hierarchical data from the
InputSource
is loaded with reflection. This way there is no behavior change for Maven versions below 4.0.0-alpha-1 with the new version of the plugin.Following this checklist to help us incorporate your
contribution quickly and easily:
for the change (usually before you start working on it). Trivial changes like typos do not
require a JIRA issue. Your pull request should address just this issue, without
pulling in other changes.
[MPH-XXX] - Fixes bug in ApproximateQuantiles
,where you replace
MPH-XXX
with the appropriate JIRA issue. Best practiceis to use the JIRA issue title in the pull request title and in the first line of the
commit message.
mvn clean verify
to make sure basic checks pass. A more thorough check willbe performed on your pull request automatically.
mvn -Prun-its clean verify
).If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.
I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
In any other case, please file an Apache Individual Contributor License Agreement.