Relative <targetPath> are resolved against the wrong directory#11322
Merged
desruisseaux merged 4 commits intoapache:masterfrom Oct 26, 2025
Merged
Relative <targetPath> are resolved against the wrong directory#11322desruisseaux merged 4 commits intoapache:masterfrom
desruisseaux merged 4 commits intoapache:masterfrom
Conversation
A dot is already automatically added by Javadoc, so these trailing dots were causing dots to appear twice in the generated Javadoc.
… the code and forces us to be more consistent since all constructions must pass by the canonical constructor. This refactored class should have the same behavior as the previous class (no new feature).
…cation in `maven.mdo`
requires that we resolve against `${project.build.outputDirectory}`, which is not `baseDir`.
Also modify the specification for resolving against `${project.build.testOutputDirectory}`
if the scope is test and `${project.build.directory}` is the scope is neither main or test.
desruisseaux
force-pushed
the
fix/relative-target-path
branch
from
cb433be to
410c4d0
Compare
…d to repeat the same code in the plugins. The `SourceRoot.targetPath(Project)` method become simpler, delegating most of the work to the new method.
desruisseaux
added a commit
to Geomatys/maven-clean-plugin
that referenced
this pull request
Oct 26, 2025
with rules consistent with apache/maven#11322.
gnodet
approved these changes
Oct 26, 2025
Contributor
gnodet
left a comment
gnodet
left a comment
There was a problem hiding this comment.
LGTM. @desruisseaux Do we need to backport that to 4.0.0 ? The modifications in the API looks binary compatible, so this looks ok.
Contributor
Author
|
Yes, it was my plan to prepare a backport if this pull request is approved. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The specification that we wrote in
maven.mdosaid about the<targetPath>element:However, the implementation in the
DefaultSourceRoot(Session session, Path baseDir, Source source)constructor resolves againstbaseDir, which is not even insidetarget.Furthermore, the specification is incomplete. The default directory should be
target/classeswhen the scope is "main", but should betarget/test-classeswhen the scope is "test". The current specification said nothing about the fact that the default value depends on the scope.This pull request is divided in 4 commits. The first commit is only trivial javadoc fixes. The second commit refactors the
DefaultSourceRootimplementation as a Java record, but without significant changes to its behaviour. The benefit of using record is to reduce the boilerplate code (the number of lines is reduced by about one third), and it also forces us to be more rigorous since all constructions must pass by the canonical constructor. The third commit is the one that actually fixes the issue described above. The last commit proposes a new method in theProjectinterface.