slachiewicz opened a new pull request, #183:
URL: https://github.com/apache/maven-doap-plugin/pull/183
Stacked on #182 (needs its `artifactHandlerManager` field) — moves
`writeReleases()`, `resolveVersioningMetadata()` and `isArtifactInRepository()`
off `ArtifactRepository` onto aether's `RemoteRepository`, the last group of
deprecation warnings that didn't have the `ProjectBuildingRequest` constraint
from #182.
`remoteRepositories` now injects `${project.remoteProjectRepositories}`
(aether-native, mirror/proxy/auth already applied by Maven at project-build
time) instead of the deprecated `${project.remoteArtifactRepositories}`. The
one caller that still needs the legacy list —
`ProjectBuildingRequest.setRemoteRepositories()` in `getMavenProject()`, which
has no aether-native overload in maven-core 3.9.16 (confirmed by reading
`DefaultProjectBuilder.InternalConfig`, which builds its resolution session and
repo list straight from
`request.getLocalRepository()`/`getRemoteRepositories()`) — gets its own
narrowly-scoped `projectBuildingRepositories` field.
`isArtifactInRepository()` drops its hand-rolled
`groupId:artifactId:type:version` coordinate string and manual
`RemoteRepository` reconstruction now that both the artifact and the repository
already arrive in proper aether form via `RepositoryUtils.toArtifact()`.
**That hand-rolled coordinate string was carrying a real, pre-existing
bug**, not just deprecation debt: aether's colon-coordinate parser treats the
third segment as the file *extension*, not the Maven *packaging* — for any
project where the two differ (this plugin's own `maven-plugin` packaging is
`.jar` on disk), the existence check silently failed and `<file-release>` was
dropped for every release, unconditionally, on `master`.
Verified empirically, not just by compiling: installed `master`'s and this
branch's plugin jar under the same GAV in turn and ran `doap:generate` against
this project's own `pom.xml` (5 real releases in central — `maven-plugin`
packaging is exactly the case that exercises the bug). `master` emits zero
`<file-release>` elements across all five releases; this branch emits all five,
and all five URLs return HTTP 200 from `repo.maven.apache.org`. This is not a
no-op refactor — it changes generated output, for the better.
Eliminates 4 of #182's remaining 7 `ArtifactRepository` warnings; the last 3
(the import, `localRepository`, `projectBuildingRepositories`) stay pinned by
`ProjectBuildingRequest` for the reason above. Also verified with `mvn
compile`, `mvn test` (13/13 — none of them reach this code path, hence the
manual verification above), and `mvn spotless:check`.
**Collision note:** #181 (MDOAP-67) also rewrites the file-release loop and
the `isArtifactInRepository` coordinate lines. Suggested merge order: #182 →
#181 → this PR; rebasing this onto #181 afterward slides
`fileReleaseType`/`fileReleaseClassifier` into the aether-native
`DefaultArtifact` construction and its `StringUtils.isNotEmpty` fix rides along.
*This change was created with AI assistance.*
--
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]
