slachiewicz opened a new pull request, #170: URL: https://github.com/apache/maven-doap-plugin/pull/170
Three components came from `maven-compat`. Two are obvious — `MavenProjectBuilder` and `ArtifactResolver` in `getMavenProject`. The third is not: `RepositoryMetadataManager`, which `writeReleases` injects, is a maven-core *interface* whose only implementation, `DefaultRepositoryMetadataManager`, ships in compat. Removing the dependency without migrating that leaves the mojo unprovisionable — Guice fails on the null field before `execute` is ever reached. `getMavenProject` now goes through maven-core `ProjectBuilder` with the request `buildFromRepository` assembled for it (`processPlugins(false)`, `VALIDATION_LEVEL_MINIMAL`, stub models allowed) and resolves through Resolver. `writeReleases` reads `maven-metadata.xml` through Resolver under an always-update policy, matching `resolveAlways`; a repository carrying no metadata for the project stays a warning rather than turning into a build failure, as it was before. `ArtifactFactory`, `ArtifactRepository` and the legacy exception types are untouched — those live in maven-core and maven-artifact. Verified: the five DOAP files the test suite generates are byte-identical to the ones master produces, apart from the generation timestamp comment. Stacked note: this and #169 both edit the dependency block but not the same hunk. Once both land, nothing pulls `wagon-provider-api` into this plugin at all. *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]
