gnodet commented on code in PR #12702:
URL: https://github.com/apache/maven/pull/12702#discussion_r3743198689
##########
impl/maven-core/src/main/java/org/apache/maven/project/collector/DefaultProjectsSelector.java:
##########
@@ -100,4 +112,26 @@ public List<MavenProject> selectProjects(List<File> files,
MavenExecutionRequest
Review Comment:
This `toBuilderProblem(ModelProblem)` method is an exact duplicate of the
one in `DefaultMaven.java`. If the conversion logic changes, both copies must
be updated in lockstep. Consider extracting to a shared utility method.
##########
impl/maven-core/src/main/java/org/apache/maven/DefaultMaven.java:
##########
@@ -660,6 +670,28 @@ private Result<? extends ProjectDependencyGraph>
buildGraph(MavenSession session
return graphResult;
}
+ /**
+ * Converts a compat {@link ModelProblem} to the Maven 4 {@link
BuilderProblem} API,
+ * preserving source, line, column, severity, and message.
+ */
+ private static BuilderProblem toBuilderProblem(ModelProblem problem) {
+ BuilderProblem.Severity severity =
+ switch (problem.getSeverity()) {
Review Comment:
The diagnostic key is generated as `"model:" +
problem.getMessage().hashCode()`. Using `String.hashCode()` for deduplication
keys is fragile — hash collisions would cause unrelated problems to be silently
deduplicated. The same pattern appears in `DefaultProjectsSelector` and the
deprecated adapters in `PluginValidationManager`.
Elsewhere in this PR, human-readable keys are used (e.g.
`"plugin-validation:contextualizable"`, `"plugin-validation:maven2-plugin"`).
Consider using a more collision-resistant approach here too — e.g.,
incorporating the problem source and a truncated/normalized message.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
