Use project repositories when building dependency POMs - #1342
Conversation
When Assembly rebuilds dependency projects, supply the repositories from the project being assembled. This avoids rechecking locally cached dependency POMs against only the session repositories. Fixes apache#1306.
There was a problem hiding this comment.
🟢 Ready to approve
The change is narrowly scoped to repository propagation, aligns with reported root cause, and is covered by both unit and integration tests.
This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.
Pull request overview
This PR fixes MASSEMBLY-1306 by ensuring the Assembly Plugin uses the assembled project’s effective remote repositories when rebuilding dependency POMs for metadata, avoiding Maven 3 “cached from a remote repository ID that is unavailable…” warnings and preventing fallback stub-project behavior.
Changes:
- Update
AddDependencySetsTaskto set theProjectBuildingRequestremote repositories fromproject.getRemoteArtifactRepositories(). - Extend the unit test to assert the repositories propagated into
ProjectBuilder. - Add a new Invoker integration test project (
massembly-1306) to verify the warning is absent and the dependency JAR is included in the produced archive.
File summaries
| File | Description |
|---|---|
| src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java | Uses the current project’s effective remote repositories when building dependency POM projects. |
| src/test/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTaskTest.java | Verifies the ProjectBuildingRequest passed to ProjectBuilder contains the project repositories. |
| src/it/projects/bugs/massembly-1306/pom.xml | Defines an IT project with a file-based repository to reproduce the missing-repo-context warning. |
| src/it/projects/bugs/massembly-1306/setup.groovy | Creates a minimal file-based repository containing a dependency POM+JAR and checksums. |
| src/it/projects/bugs/massembly-1306/src/assembly/dist.xml | Assembles dependencies into a ZIP to confirm dependency inclusion under the corrected behavior. |
| src/it/projects/bugs/massembly-1306/verify.groovy | Asserts the warning is absent in build.log and the dependency JAR is present in the ZIP. |
Review details
- Files reviewed: 6/6 changed files
- Comments generated: 0
- Review effort level: Lite
We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.
elharo
left a comment
There was a problem hiding this comment.
Is there any way to do this without using the deprecated classes like org.apache.maven.artifact.repository.ArtifactRepositoryPolicy? I won't be surprised if the answer is no, but if so we might want to undeprecate those.
Fixed. |
Fixes #1306.
Summary
Use the repositories configured for the project being assembled when the
Assembly Plugin rebuilds dependency projects to obtain their POM metadata.
This prevents Maven 3 from repeatedly warning that a locally cached dependency
POM came from a repository unavailable in the current build context when that
repository is declared by the assembly project rather than in the session's
initial project-building request.
Root cause
AddDependencySetsTaskcreates aProjectBuildingRequestfor each dependencyby copying the Maven session request. That copied request does not necessarily
contain repositories contributed by the effective assembly project. Maven
therefore attempted to verify the dependency POM against Central alone,
emitted the unavailable-repository warning, and fell back to a stub project.
The copied request now uses
project.getRemoteArtifactRepositories(), retainingthe repositories Maven calculated for the project being assembled.
The unit test verifies that these repositories reach
ProjectBuilder. The newInvoker project creates a dependency in a private file repository, verifies
that the warning is absent, and checks that the dependency JAR remains present
in the resulting archive. Before the implementation change, this integration
test failed because the warning appeared twice.
Compatibility and verification
mvn clean verifypassed with 268 unit tests.Following this checklist to help us incorporate your
contribution quickly and easily:
Note that commits might be squashed by a maintainer on merge.
This may not always be possible but is a best-practice.
mvn verifyto make sure basic checks pass.A more thorough check will be performed on your pull request automatically.
mvn -Prun-its verify).If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.