gnodet commented on PR #11394:
URL: https://github.com/apache/maven/pull/11394#issuecomment-3499840550
## Implementation Details
I've implemented a fix for this issue that ensures `SourceRoot.targetPath()`
and `ConnectedResource` behave correctly according to the Maven 4 API while
preserving Maven 3 compatibility.
### Root Cause
The regression occurred because `DefaultSourceRoot.fromModel()` was storing
`targetPath` as an **absolute path** (resolved against `baseDir` and
`outputDir`), when it should have been stored as a **relative path** according
to the Maven 4 API design.
### Maven 4 API Design
The Maven 4 API defines two methods for `SourceRoot`:
1. **`targetPath()`** - Returns an `Optional<Path>` containing the explicit
target path. According to the javadoc and the presence of the resolution method
below, this should be a **relative path** (or absolute if explicitly specified
as absolute).
2. **`targetPath(Project)`** - Returns the resolved absolute path by taking
the relative `targetPath()` and resolving it against the project's output
directory:
```java
Path base = project.getOutputDirectory(scope());
return targetPath.map(base::resolve).orElse(base);
```
This two-method design clearly indicates that `targetPath()` should return a
**relative** path that gets resolved by `targetPath(Project)`.
### Implementation
**1. Fixed `DefaultSourceRoot.fromModel()`** (impl/maven-impl)
```java
// Before (incorrect):
nonBlank(source.getTargetPath())
.map((targetPath) ->
baseDir.resolve(outputDir.apply(scope)).resolve(targetPath))
.orElse(null)
// After (correct):
nonBlank(source.getTargetPath()).map(Path::of).orElse(null)
```
Now `targetPath()` returns a **relative path** as intended, and
`targetPath(Project)` handles the resolution.
**2. Simplified `ConnectedResource.computeRelativeTargetPath()`**
(impl/maven-core)
Since `SourceRoot.targetPath()` now always returns a relative path, we can
simply return it as-is:
```java
return sourceRoot.targetPath().map(Path::toString).orElse(null);
```
This removed ~40 lines of complex logic that was trying to convert absolute
paths back to relative paths.
### Maven 3 Compatibility
In Maven 3, `Resource.getTargetPath()` was always **relative to the output
directory**. This behavior is preserved:
- `SourceRoot.targetPath()` stores the path as relative (e.g.,
`"custom-dir"`)
- `ConnectedResource` converts it back to a String for the Maven 3
`Resource` API
- Resources are copied to `target/classes/custom-dir` (Maven 3 behavior) ✅
### Example
With `<targetPath>custom-dir</targetPath>` in a resource configuration:
- **Maven 3**: Resources copied to `target/classes/custom-dir` ✅
- **Maven 4 (before fix)**: Resources copied to `project-root/custom-dir` ❌
- **Maven 4 (after fix)**: Resources copied to `target/classes/custom-dir` ✅
### Testing
All existing tests pass, including:
- `DefaultSourceRootTest` - Updated to expect relative paths from
`targetPath()`
- `ResourceIncludeTest` - Validates the Maven 3 compatibility layer
- Integration test `MavenITgh11381ResourceTargetPathTest` should now pass
The fix is minimal, focused, and aligns with the Maven 4 API design while
maintaining backward compatibility.
--
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]
