You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "slachiewicz (via GitHub)" <gi...@apache.org> on 2026/09/11 19:38:17 UTC
[PR] Move release/metadata resolution off ArtifactRepository to aether RemoteRepository [maven-doap-plugin]
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Move release/metadata resolution off ArtifactRepository to aether RemoteRepository [maven-doap-plugin]
Posted by "slachiewicz (via GitHub)" <gi...@apache.org>.
slachiewicz merged PR #183:
URL: https://github.com/apache/maven-doap-plugin/pull/183
--
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: issues-unsubscribe@maven.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org