-
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-7754] Improvement and extension of plugin validation #1079
[MNG-7754] Improvement and extension of plugin validation #1079
Conversation
As it seems is confusing to some users --- https://issues.apache.org/jira/browse/MNG-7754
…essages. They are now reported at end.
Fixed ITs to not fail: - assert only for content, neglect and possible indentation - do not assert what is NOT warn logged, as later we may log more (IT would be not future proof) Tested with 3.9.1 and 3,9,2-SNAPSHOT w/ apache/maven#1079 Both passes OK
IT fix apache/maven-integration-testing#256 |
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.
Looking at the output:
[WARNING] * 70 : 15, org.apache.maven:maven-settings-builder:3.9.2-SNAPSHOT /home/cstamas/Worx/apache-maven/maven/maven-settings-builder/pom.xml
[WARNING] * 131 : 15, org.apache.maven:maven-resolver-provider:3.9.2-SNAPSHOT /home/cstamas/Worx/apache-maven/maven/maven-resolver-provider/pom.xml
[WARNING] * 192 : 15, org.apache.maven:maven-core:3.9.2-SNAPSHOT /home/cstamas/Worx/apache-maven/maven/maven-core/pom.xml
I don't understand how to read those numbers and to what they relate.
|
||
@Override | ||
public void validate(MavenSession mavenSession, MojoDescriptor mojoDescriptor) { | ||
if (mojoDescriptor.getPluginDescriptor() != 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.
Can they be null?! Weird
...e/src/main/java/org/apache/maven/plugin/internal/AbstractMavenPluginParametersValidator.java
Show resolved
Hide resolved
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultMavenPluginManager.java
Outdated
Show resolved
Hide resolved
...n-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginDependenciesResolver.java
Show resolved
Hide resolved
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java
Outdated
Show resolved
Hide resolved
...n-core/src/main/java/org/apache/maven/plugin/internal/DeprecatedCoreExpressionValidator.java
Outdated
Show resolved
Hide resolved
maven-core/src/main/java/org/apache/maven/plugin/internal/Maven2DependenciesValidator.java
Outdated
Show resolved
Hide resolved
if (mavenVersions.size() > 1) { | ||
pluginValidationManager.reportPluginValidationIssue( | ||
mavenSession, mojoDescriptor, "Plugin mixes multiple Maven versions: " + mavenVersions); | ||
} |
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.
How to understand this message?
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.
Unsure how to put it in words, but the point is that "among plugin dependencies there are maven artifacts that has different versions" -- kinda like "dep convergence" but for maven? There are some shared stuff (maybe older filtering) that caused this, especially as they pulled in maven-project, artifact that is gone from maven 3, so even depMgt could not "align" it as it was maven2 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.
Now I see, from the message it is hard to derive that.
.../main/java/org/apache/maven/plugin/internal/PlexusContainerDefaultDependenciesValidator.java
Outdated
Show resolved
Hide resolved
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 would like to put sections:
- Declared at location(s)
- Used in module(s)
as optional - default disabled - in projects with hundred modules such message will make more mess than benefit
maybe we can have a option
maven.plugin.validation
with values:
dafault
verbose
with location and modulesfalse
- disbaled at all
...e/src/main/java/org/apache/maven/plugin/internal/AbstractMavenPluginParametersValidator.java
Show resolved
Hide resolved
...e/src/main/java/org/apache/maven/plugin/internal/AbstractMavenPluginParametersValidator.java
Outdated
Show resolved
Hide resolved
...n-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginDependenciesResolver.java
Show resolved
Hide resolved
maven-core/src/main/java/org/apache/maven/plugin/internal/Maven2DependenciesValidator.java
Outdated
Show resolved
Hide resolved
maven-core/src/main/java/org/apache/maven/plugin/internal/MavenMixedDependenciesValidator.java
Outdated
Show resolved
Hide resolved
maven-core/src/main/java/org/apache/maven/plugin/internal/MavenScopeDependenciesValidator.java
Outdated
Show resolved
Hide resolved
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java
Outdated
Show resolved
Hide resolved
Applied PR comments and proposals |
If user set anything, fail if value is junk
I don't even know what those numbers mean, can you point me to the source where it comes from? |
They point to POM sources: |
What about:
|
this is much better, we can leverage an improvement (#756) from @hboutemy recently:
which might even shorten the output. The rest is from |
The improvement is already in, in the "Used in module(s)" section, see https://gist.github.com/cstamas/b62fdcd53eaf316123cf183f5a24e6a5#file-gistfile1-txt-L39 But here I have no idea how to reformat location... any example? |
Right, but not here: https://gist.github.com/cstamas/b62fdcd53eaf316123cf183f5a24e6a5#file-gistfile1-txt-L71-L75 As a user is just causes confusion, not clarification. |
Updated gist with new output. Removed |
Updated gist once more: since last, removed "from" repeated string, only path alone is in braces. If within TLP, is relative, otherwise is abs (ie. from local repo). |
I wonder if the |
Agreed, and removed |
stringBuilder.append(inputLocation.getSource().getModelId()); | ||
String location = inputLocation.getSource().getLocation(); | ||
if (location != null) { | ||
if (location.contains("://")) { |
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.
You assume that this can be a URL?
Interesting, invoked
How does site plugin come in picture for ANY of these? |
Lifecycle binding? |
Huh? for BTW, the message means site plugin is |
Eager plugin scanning in core?`Remove maven-site-plugin from local repo and try again. This might prove my theory. |
...n-core/src/main/java/org/apache/maven/plugin/internal/DeprecatedCoreExpressionValidator.java
Outdated
Show resolved
Hide resolved
…ecatedCoreExpressionValidator.java Co-authored-by: Konrad Windszus <konrad_w@gmx.de>
This is general rework of current Maven 3.9.x line how it handles plugin and mojo validations. Changes: * added plugin validations for dependencies * introduced pluginValidationManager that gathers violations * manager creates a report at build end, with dense and non repeating data * this is in spirit to lessen already too verbose logging, as current solution would report violations as many times plugin is used in reactor, and that can be many (ie. a plugin from parent for each module) Example report of Maven 3.9.x build: https://gist.github.com/cstamas/b62fdcd53eaf316123cf183f5a24e6a5 --- https://issues.apache.org/jira/browse/MNG-7754
This is general rework of current Maven 3.9.x line how it handles plugin and mojo validations. Changes: * added plugin validations for dependencies * introduced pluginValidationManager that gathers violations * manager creates a report at build end, with dense and non repeating data * this is in spirit to lessen already too verbose logging, as current solution would report violations as many times plugin is used in reactor, and that can be many (ie. a plugin from parent for each module) Example report of Maven 3.9.x build: https://gist.github.com/cstamas/b62fdcd53eaf316123cf183f5a24e6a5 --- https://issues.apache.org/jira/browse/MNG-7754
This is general rework of current Maven 3.9.x line how it handles plugin and mojo validations.
Changes:
Example report of Maven 3.9.x build: https://gist.github.com/cstamas/b62fdcd53eaf316123cf183f5a24e6a5
https://issues.apache.org/jira/browse/MNG-7754