New feature, improvement proposal
The README describes maven-executor as dependency-less, and the POM agrees: the jar has no compile-scope dependencies. The only shipped ExecutorTool implementation does not, though. ToolboxExecutorTool answers localRepository(), artifactPath(), metadataPath(), and dump() by running eu.maveniverse.maven.plugins:toolbox:VERSION:gav-* through the Maven under test (ToolboxExecutorTool.java:45,134). Every consumer that needs an artifact path therefore fetches a plugin from a non-ASF group at test time, and the plugin and its transitive dependencies land in the local repository that the tests run against.
This matters for the projects that MIGRATION.md in maven-verifier tells to move here. maven-verifier computes those paths locally, and its integration tests assert on local-repository content: in maven-integration-testing alone deleteArtifacts is called 302 times and verifyArtifactPresent 84 times. After migration each of those calls depends on:
- network access to Maven Central for a plugin outside the ASF, which offline and air-gapped CI cannot provide;
- the toolbox artifacts appearing in the local repository under test, which changes what "artifact not present" assertions see;
- a pinned third-party version (
0.15.8 in the deprecated constructor, version.toolbox in the POM) that ASF release policy does not cover.
The maven-it-helper Verifier in apache/maven already carries this: it wires ToolboxExecutorTool at construction and reads version.toolbox from a system property, so the core ITs cannot run without the plugin.
Proposal:
- Provide an
ExecutorTool implementation that computes local-repository, artifact, and metadata paths without executing a plugin. dump() needs Maven, but the three path methods only need the effective local repository and the standard layout, which maven-verifier has implemented for years and which Maven 3.9 and 4 share.
- Keep
ToolboxExecutorTool as an opt-in for dump() and for anyone who wants the toolbox, and state in the README and Javadoc that it downloads and runs a third-party plugin.
- Change the README wording from "dependency-less" to describe the runtime requirement, or keep the wording once step 1 makes it true for the default path.
Context: apache/maven-verifier#186.
New feature, improvement proposal
The README describes
maven-executoras dependency-less, and the POM agrees: the jar has no compile-scope dependencies. The only shippedExecutorToolimplementation does not, though.ToolboxExecutorToolanswerslocalRepository(),artifactPath(),metadataPath(), anddump()by runningeu.maveniverse.maven.plugins:toolbox:VERSION:gav-*through the Maven under test (ToolboxExecutorTool.java:45,134). Every consumer that needs an artifact path therefore fetches a plugin from a non-ASF group at test time, and the plugin and its transitive dependencies land in the local repository that the tests run against.This matters for the projects that MIGRATION.md in maven-verifier tells to move here.
maven-verifiercomputes those paths locally, and its integration tests assert on local-repository content: inmaven-integration-testingalonedeleteArtifactsis called 302 times andverifyArtifactPresent84 times. After migration each of those calls depends on:0.15.8in the deprecated constructor,version.toolboxin the POM) that ASF release policy does not cover.The
maven-it-helperVerifier inapache/mavenalready carries this: it wiresToolboxExecutorToolat construction and readsversion.toolboxfrom a system property, so the core ITs cannot run without the plugin.Proposal:
ExecutorToolimplementation that computes local-repository, artifact, and metadata paths without executing a plugin.dump()needs Maven, but the three path methods only need the effective local repository and the standard layout, whichmaven-verifierhas implemented for years and which Maven 3.9 and 4 share.ToolboxExecutorToolas an opt-in fordump()and for anyone who wants the toolbox, and state in the README and Javadoc that it downloads and runs a third-party plugin.Context: apache/maven-verifier#186.