slachiewicz commented on issue #13302:
URL: https://github.com/apache/maven/issues/13302#issuecomment-5919282431
### Wave 4 findings, part 1 of 4: maven-acr-plugin to maven-dependency-plugin
Each plugin is a local branch `agent/mvn4-api` with a "Build with Maven 4
only" commit and a "Port to the Maven 4 API" commit; the PRs are not opened yet.
<details><summary><b>maven-acr-plugin</b>: ported</summary>
Branch `agent/mvn4-api`; PR not opened yet. Status: **ported**,
4.0.0-beta-1-SNAPSHOT (was 3.2.1-SNAPSHOT), Java 17.
Verified locally: Maven 4.0.0-rc-7, JDK 21. `mvn verify` → BUILD SUCCESS
before and after; the plugin has no unit tests (0 before, 0 after). `mvn verify
-Prun-its` → 4/4 invoker ITs pass before (3m20s) and after; `spotless:check`
clean. Consumed released artifacts only, no local snapshots: maven-archiver
4.0.0-beta-5, maven-filtering 4.0.0-beta-1, maven-plugin-plugin 4.0.0-beta-1.
**User-visible changes**
- `AcrMojo` implements `org.apache.maven.api.plugin.Mojo`, annotated with
`org.apache.maven.api.plugin.annotations`; project, session, `Log`,
`ProjectManager` and `MavenFileFilter` are `@Inject`ed. Goal `acr`, phase
`package` and every parameter name/property (`maven.acr.*`, `jarName`,
`excludes`, `archive`, `filters`, `outputTimestamp`) are unchanged; `basedir`
and `outputDirectory` are now `Path` (same XML syntax).
- Runs only on Maven 4: it no longer loads under Maven 3 (`javax.inject`,
`maven-plugin-api`, `maven-core`, `maven-artifact` dropped). A 3.x line has to
stay for Maven 3 users.
- Main artifact is attached with `ProjectManager.attachArtifact(project,
project.getMainArtifact(), jar)` instead of `project.getArtifact().setFile`.
- Bug fixed on the way: the old code appended
`META-INF/application-client.xml` to the user's `excludes` list in place; it
now copies the list.
- New `Providers` class (`@Provides`) supplies `ProjectManager` and
`BuildContext`; the second is needed because `DefaultMavenFileFilter`
4.0.0-beta-1 requires a `BuildContext` binding (the same workaround
maven-resources-plugin carries). Without both, every IT failed with "No binding
to construct an instance for key ...".
**Gaps**
- `org.eclipse.sisu:org.eclipse.sisu.plexus` must be a compile dependency:
`ThreadBuildContext` (plexus-build-api 0.0.7) needs
`org.codehaus.plexus.logging.AbstractLogEnabled`, which the v4 plugin realm
does not provide. The four ITs pass without it (the
`<extensions>true</extensions>` realm supplies the class), but invoking the
goal directly on a jar-packaged project (`mvn
...:maven-acr-plugin:4.0.0-beta-1-SNAPSHOT:acr`) failed with "Unable to lookup
Mojo" until the dependency was added; afterwards it built the jar.
maven-resources-plugin master carries the same dependency.
- `@Mojo(dependencyResolutionPathScopes = "runtime")` (the v4 replacement
for `requiresDependencyResolution = RUNTIME`) cannot be used:
maven-plugin-plugin 4.0.0-beta-1 fails with "Method:
'dependencyResolutionPathScopes' not found in class MojoAnnotationContent". The
attribute is omitted; this is safe here because `MavenArchiver.getManifest`
resolves `MAIN_RUNTIME` on demand through `DependencyResolver`, which is what
all four ITs exercise (manifest classpath included).
- The `app-client` packaging still needs `META-INF/plexus/components.xml`
(`LifecycleMapping` + `ArtifactHandler`). A pure v4 registration via
`PackagingProvider` + `TypeProvider` compiled and its beans were indexed, but
with the components.xml removed and a clean build, it-01 failed with `Unknown
packaging: app-client`. `DefaultPackagingRegistry.lookup` in maven-4.0.x
resolves only through the Sisu `LifecycleMapping` component and never consults
`PackagingProvider`, so the SPI is inert. The experiment was reverted; the file
is unchanged and works under rc-7.
- `maven-plugin-testing` v4 harness was not added: no unit test existed to
port.
**Improvements:** drops `javax.inject`, `maven-plugin-api`, `maven-core`,
`maven-artifact`, `maven-plugin-annotations`, `plexus-utils` (`FileUtils`
replaced by `java.nio.file.Files`). Adds `maven-api-core/di/annotations`
(provided), `plexus-build-api` and `org.eclipse.sisu.plexus`.
**Recommendation:** port for Maven 4; keep a 3.x line for Maven 3 builds.
Follow up upstream on two items: `PackagingProvider` not honoured by
`DefaultPackagingRegistry` (blocks removing components.xml from packaging
plugins), and maven-plugin-tools not extracting
`dependencyResolutionPathScopes`.
</details>
<details><summary><b>maven-antrun-plugin</b>: ported</summary>
Branch `agent/mvn4-api`; PR not opened yet. Status: **ported** (two
workarounds for Maven 4.0.0-rc-7 defects), 4.0.0-beta-1-SNAPSHOT, Java 17.
Verified locally: `mvn verify -Prun-its` with Maven 4.0.0-rc-7, JDK 21 → 4
unit tests and 29 invoker ITs before, 4 and 29 after, 0 failures (before 9:52
min, after 10:08 min); spotless clean. The "before" numbers are the 3.2.1 code
built and run by Maven 4.
**Ant-visible references** (all registered on the Ant project by
`AntRunMojo`)
| Reference | Before | After |
|---|---|---|
| `maven.compile.classpath`, `maven.dependency.classpath`,
`maven.runtime.classpath`, `maven.test.classpath` | `Path` from
`MavenProject.get*ClasspathElements()` | same ids and type; built from output
directories plus `Session.resolveDependencies(project, MAIN_COMPILE /
MAIN_RUNTIME / TEST_RUNTIME)` |
| `maven.plugin.classpath` | `Path` from `${plugin.artifacts}` | same id and
type; built from the `URLClassLoader` URLs of
`MojoExecution.getPlugin().getClassLoader()` (see Gaps) |
| `maven.project` | `org.apache.maven.project.MavenProject` | changed type:
`org.apache.maven.api.Project` |
| `maven.project.ref` | `MavenAntRunProject` holding a `MavenProject` | same
id; `getMavenProject()` now returns `org.apache.maven.api.Project` |
| `maven.project.helper` | `MavenProjectHelper` | **disappears**;
`maven.session` replaces it (attach goes through
`ProjectManager.attachArtifact`) |
| `maven.local.repository` | aether `LocalRepository` (`getBasedir()`) |
changed type: `org.apache.maven.api.LocalRepository` (`getPath()`) |
| `maven.local.repository.manager` | aether `LocalRepositoryManager` |
**disappears**; `Session.getPathForLocalArtifact` via `maven.session` |
| `maven.session` | none | new: `org.apache.maven.api.Session` |
| `maven.dependency.artifacts` | none | new: `List<MavenAntRunDependency>`
(dependency + path); replaces `MavenProject.getArtifacts()` for the tasks |
Unchanged: the Ant properties (`project.*`, `localRepository`,
`settings.localRepository`, one property per dependency conflict id,
`maven.project.dependencies.versions`), the `maven.project.dependencies`
fileset and the per-artifact filesets, and the `mvn:attachartifact` /
`mvn:dependencyfilesets` task names and attributes.
**Public API changes**
- `AntRunMojo` implements `org.apache.maven.api.plugin.Mojo` (was
`AbstractMojo`); `execute()` throws `MojoException`;
`DEFAULT_MAVEN_PROJECT_HELPER_REFID` removed, `DEFAULT_MAVEN_SESSION_REFID` and
`DEFAULT_MAVEN_DEPENDENCIES_REFID` added; `copyProperties` takes
`org.apache.maven.api.Project` plus the resolved dependencies;
`getLocalRepository()` returns `org.apache.maven.api.LocalRepository`.
- `MavenAntRunProject`, `MavenLogger` (now takes `api.plugin.Log`),
`DependencyFilesetsTask.filterArtifacts` (`List<MavenAntRunDependency>`),
`SpecificScopesArtifactFilter` and `TypesArtifactFilter` (now
`Predicate<org.apache.maven.api.Dependency>`) change signature. New
`MavenAntRunDependency` record.
- Parameters: `${plugin.artifacts}` and `${repositorySystemSession}` are no
longer injected; `sourceRoot` / `testSourceRoot` (removed, fail-fast) are
`String` instead of `File`; `@Mojo(threadSafe, requiresDependencyResolution)`
has no v4 attribute in use, dependencies are resolved on demand in `execute()`.
- `AntrunXmlPlexusConfigurationWriter` (package-private) is replaced by
`AntrunXmlConfigurationWriter` over `XmlNode`; output is identical for the 4
existing writer tests.
**Gaps**
- An `XmlNode`-typed `@Parameter` drops every XML attribute and namespace:
`DefaultBeanConfigurator.XmlConverter.toXml` calls `XmlNode.newInstance(name,
value, null, children, null)`. Ant tasks are attribute-based, so the plugin
reads `<target>` from `MojoExecution.getConfiguration()` instead; the injected
`target` field stays only as the declared parameter. Consequence: runtime Maven
expressions inside `<target>` that are not resolved at model time (for example
`${session...}`) are no longer evaluated by Maven; no IT covers them.
- `MojoExecution.getPlugin().getDependencies()` throws an NPE from the
second plugin execution in a build (`DefaultMojoExecution.getDependenciesMap`
uses a null `PluginDescriptor.getDependencyNode()`); reproduced by the
`multiple-phase-test` IT. `maven.plugin.classpath` is taken from the plugin
realm URLs instead, which includes dependencies added in the project's
`<plugin><dependencies>`.
- No `PathScope` contains the `system` dependency scope (`test-runtime` =
compile, provided, test, runtime, test-runtime), so system-scoped dependencies
are absent from the classpaths, properties and filesets. No IT covers it.
- No `MojoFailureException`: every Ant failure is a `MojoException` (build
failure vs. error is lost).
- `Build.getSourceDirectory()` and `getTestSourceDirectory()` are deprecated
in the v4 model and still feed `project.build.sourceDirectory`; projects that
only declare `<sources>` are not covered.
- Anything a user script does with `MavenProject` through `maven.project`
(`getArtifacts()`, `addCompileSourceRoot`, `getProperties()`…) has no direct v4
equivalent on `api.Project`.
- Site pages (`usage`, `tasks/*`) still describe the old references; not
updated.
**User-visible changes:** requires Maven 4; the reference and parameter
changes above; Ant scripts or custom tasks that cast `maven.project` to
`MavenProject`, read `maven.project.helper` or `maven.local.repository.manager`
break. No Java code under the Apache Maven repositories imports the changed
types (grep over `org.apache.maven.plugins.antrun` /
`org.apache.maven.ant.tasks`); POM users of the plugin were not inspected.
**Improvements:** drops `maven-plugin-api`, `maven-core`, `maven-artifact`,
`maven-model`, `maven-plugin-annotations`, `javax.inject`,
`org.eclipse.sisu.plexus`, `plexus-utils`, `plexus-xml`; adds
`maven-api-core/annotations/model/xml/di` (provided). No MXSerializer.
**Recommendation:** port for Maven 4 plugins and keep a 3.x line for Maven 3
users. Before merging, ask Maven core for attribute-preserving `XmlNode`
parameters (or document `MojoExecution.getConfiguration()`) and fix the null
dependency node in `DefaultMojoExecution`.
</details>
<details><summary><b>maven-artifact-plugin</b>: partial</summary>
Branch `agent/mvn4-api`; PR not opened yet. Status: **partial**,
4.0.0-beta-1-SNAPSHOT (was 3.7.1-SNAPSHOT), Java 17. `buildinfo`, `compare`,
`describe-build-output` and `check-buildplan` are ported;
`reproducible-central` compiles but cannot run, and one IT cannot pass.
Verified locally: Maven 4.0.0-rc-7, JDK 21. `mvn verify` before → 2 tests, 0
failed, 0 skipped; after → 25 tests, 0 failed, 0 skipped, but only with
`-Dpgpverify.skip=true` (see Gaps). `mvn verify -Prun-its` before → 13 passed,
3 failed (`git-mono`, `git-multi`, `describe-multi`), 0 skipped (12m10s); after
→ 12 passed, 4 failed (the same three, plus `buildinfo-dir`), 0 skipped
(17m18s), both run on a copy of the tree. The three common failures are not
caused by the plugin: `git-*` stop in git-commit-id-plugin with "Could not get
HEAD Ref" (the copied tree has no commits), `describe-multi` stops in
apache-rat on `build.log.1` and the Maven 4 consumer POM. `spotless:check`
clean. Consumed: released
`org.apache.maven.shared:maven-archiver:4.0.0-beta-5`, and the local snapshots
`maven-reporting-impl` and `maven-reporting-api` 5.0.0-SNAPSHOT (branch
`agent/mvn4-api` of maven-reporting-impl, commit 21c3da4, already in the local
repository, not rebuilt).
**User-visible changes**
- Goals `buildinfo`, `compare`, `describe-build-output`, `check-buildplan`,
`reproducible-central` keep their names, phases and parameters (`buildinfo.*`,
`reference.repo`, `compare.*`, `check.*`, `diagnose`, `outputTimestamp`);
`buildinfoFile` and `check.plugin-issues` are now `Path`. `threadSafe` is gone
from `@Mojo` (the API annotation has none). Runs only on Maven 4: a 3.x line
has to stay.
- `RangesUtil` is no longer a Sisu component: it is a static utility
returning `RangeDependency` records (`groupId`, `artifactId`, `version`,
`message`).
- `compare`: the reference is the file of the local repository when there is
one (installed, or cached from the reference repository), else it is downloaded
from the reference repository with the `Transport` service, without looking at
the reactor. The log line "Comparing against N reference files from ..." now
shows `id (url)`.
- `check-buildplan`: the plan is computed from the effective POM (see Gaps).
- Dependency range messages are unchanged on the ITs (`Dependency g:a:jar:v
(scope) via ... has been resolved from a version range [a,b)`).
**Gaps**
- `check-buildplan` has no v4 route to
`LifecycleExecutor.calculateExecutionPlan` / `MavenExecutionPlan`. The plugins
of the plan are the plugins of the effective POM's `build/plugins` (Maven 4
injects the packaging bindings there) that have an execution with goals in a
phase up to the phase of a task (Maven 3 phase names matched through
`Lifecycle.aliases()`) or in no phase. Not covered: tasks that are goals
(`-Dcheck.buildplan.tasks=foo:bar`), plugins forked by `@Execute`, and
executions whose phase only comes from the goal's default phase in a plugin
descriptor when the POM gives none (those are counted as in the plan, which can
over-report). The five `check-buildplan-*` ITs pass.
- Version ranges: `Node` carries no `VersionConstraint`, so direct ranges
come from `Project.getDependencies()` (overlaid with
`getManagedDependencies()`), and transitive ones from building the POM of every
node of the graph with `ProjectBuilder`. A dependency whose POM cannot be
resolved or built hides the ranges of its own dependencies; relocated
dependencies are not followed. `check-buildplan-version-range-*` and
`compare-mono` (buildinfo `mvn.rebuild-args`) pass.
- `compare` has no resolver provenance: `DownloadedArtifact` gives a path,
not the repository. "Installed locally" is read from `_remote.repositories`
(`file>=`), which resolver documents as internal. Workspace-free download uses
`TransportProvider`; `Session.createRemoteRepository` does not apply mirrors to
an `id::url` or `url` reference repository (not measured).
- `reproducible-central` compiles against `maven-reporting-impl`
5.0.0-SNAPSHOT, but `mvn
org.apache.maven.plugins:maven-artifact-plugin:4.0.0-beta-1-SNAPSHOT:reproducible-central`
fails with `NoClassDefFoundError: org/apache/maven/execution/MavenSession`:
the Doxia site tool behind `AbstractMavenReport` needs Maven 3 types that the
plugin realm of a Maven 4 plugin does not see (the same blocker as the
reporting-impl port). No IT covers this goal.
`@Mojo(requiresDependencyResolution = RUNTIME)` cannot be written either
(`dependencyResolutionPathScopes` is not extracted by maven-plugin-plugin
4.0.0-beta-1); the report collects the runtime graph itself.
- IT `buildinfo-dir` (MARTIFACT-26) fails: it expects the warning "Ignoring
artifact ...:pom:4.3.10 because it points to inexistent ..." for the main
artifact of a `pom`-packaged module. In the v4 API a `pom` project has no main
artifact (`Project.getMainArtifact()` is empty unless there are two artifacts),
so there is nothing to warn about. The buildinfo itself is written correctly.
The IT is unchanged.
- `mvn verify` runs pgpverify: its keys map has no entries for the new
artifacts, and the locally built rc-7 artifacts are unsigned, so the goal
fails; `pgp-keys-map.list` is not updated.
- `Session` has no top-level project: `Project.isTopProject()` is used;
`MavenProject.getOriginalModel()` is read back from the POM file with
`ModelXmlFactory`.
Tests: the two existing tests are unchanged. New: `RangesUtilTest`,
`CheckBuildPlanMojoTest`, `PluginUtilTest`, `LocalRepositoryOriginTest`,
`OutputArtifactTest` (23 tests).
**Improvements:** drops `maven-plugin-api`, `maven-core`, `maven-model`,
`maven-artifact`, `maven-resolver-api`, `maven-resolver-util`, `plexus-utils`,
`plexus-xml`, `commons-io`, `javax.inject` and `maven-plugin-annotations` (the
Maven 3 `maven-archiver` 3.6.6 is replaced by 4.0.0-beta-5, used only for
`parseBuildOutputTimestamp`). Adds `maven-api-core/di/annotations` and
`maven-xml` (provided) and the two reporting snapshots.
**Recommendation:** port for Maven 4 and keep a 3.x line for Maven 3. Do not
release before the reporting chain is ported: the report goal cannot run.
Upstream follow-ups worth filing: expose the repository of a resolved artifact
and a way to resolve without the workspace; put `VersionConstraint` (and the
pre-managed version) on `Node`; give the API an execution-plan service for
tasks.
</details>
<details><summary><b>maven-assembly-plugin</b>: ported</summary>
Branch `agent/mvn4-api`; PR not opened yet. Status: **ported**,
4.0.0-beta-1-SNAPSHOT, Java 17. Needs an unreleased plexus-archiver (see Gaps,
first item).
Verified locally: `mvn verify` with Maven 4.0.0-rc-7, JDK 21 → 273 unit
tests before, 271 after, 0 failures/errors/skipped both (3 tests removed, 1
added, listed below); checkstyle, RAT, dependency:analyze and `spotless:check`
pass. `mvn verify -Prun-its` (155 project ITs): the before run hit the 30 min
time-box after 65 ITs (65 passed, 0 failed; `exit=143`). After: the same 65 →
65 passed in 7 min, and the other 90 → 89 passed, 1 failed
(`depSet-transFromProfile`, which the POM's own `pomExcludes` excludes from
`run-its`; I listed it by hand, so it is not a regression). The ITs ran as two
`-Dinvoker.test=` batches (the 65 that finished before, then the remaining 90)
because the full profile exceeds the time-box on this machine. Shared snapshots
consumed: maven-archiver 4.0.0-beta-6-SNAPSHOT, maven-filtering
4.0.0-beta-2-SNAPSHOT, maven-common-artifact-filters 4.0.0-SNAPSHOT (all from
their local `agent/mvn4-api`/master worktrees), plexus-archiver 5.0.0-SNAPSHOT
(master plus
a 4-line local patch, `asm-plexus-archiver-prototype.diff`). maven-mapping is
not a dependency of the plugin (no import, not in the tree), so nothing is lost
there.
**Public API changes** (for people who call or extend the plugin classes;
the descriptor model `Assembly`, `ModuleSet`, ... is unchanged)
- `AbstractAssemblyMojo` implements `org.apache.maven.api.plugin.Mojo`;
services are `@Inject` fields (`Session`, `Project`, `Log`, `MojoExecution`,
`AssemblyArchiver`, `AssemblyReader`, `MavenReaderFilter`). The four-argument
constructor is gone.
- `AssemblerConfigurationSource`: `MavenProject` →
`org.apache.maven.api.Project`, `MavenSession getMavenSession()` → `Session
getSession()`, `MavenArchiveConfiguration` is now
`org.apache.maven.shared.archiver` (its `getManifestFile()` is a `Path`).
- New `artifact.AssemblyArtifact` replaces
`org.apache.maven.artifact.Artifact` throughout (resolver, tasks, filters). The
v4 API splits coordinates (`Dependency`), file and dependency trail;
`AssemblyArtifact` holds all three and keeps the v3 getter names that
`${artifact.*}` / `${module.*}` expressions use.
- `ProjectBuilder`, `ArtifactHandlerManager`, `RepositorySystem`,
`PlexusContainer`, `BasicComponentConfigurator` are no longer constructor
arguments of the phases, the resolver and `DefaultAssemblyArchiver`.
`AddDependencySetsTask` and `ModuleSetAssemblyPhase` lose their
`ProjectBuilder` parameter; `FilterUtils.filterProjects` gains a `Session`.
- `AssemblyProxyArchiver` no longer implements the deprecated `Archiver`
methods (`addDirectory(...)`, `addArchivedFileSet(File, ...)`, `getFiles`,
`setUseJvmChmod`, `setLastModifiedDate`, ...): plexus-archiver 5.0 removed them.
- `ContainerDescriptorHandler` SPI is unchanged (`ArchiveFinalizer` +
`FileSelector`); how handlers are found changed, see Gaps.
**Gaps** (what has no v4 equivalent or had to be worked around; each
verified by a concrete failure)
- **`ArchiverManager` cannot be obtained without Sisu in a v4 mojo, and
plexus-archiver's "no DI" mode is incomplete.** Probe plugin on rc-7:
`Lookup.lookup(ArchiverManager.class)` → `NoSuchElementException`;
`lookupMap(ArchiverManager.class)` is empty. Cause: `DefaultArchiverManager`
(plexus-archiver
`src/main/java/org/codehaus/plexus/archiver/manager/DefaultArchiverManager.java`)
is a `javax.inject` `@Named @Singleton` bean whose constructor takes
`Map<String, Provider<Archiver>>` etc., a Sisu-only hint-keyed map, and Maven 4
registers `javax.inject` `@Named("hint")` beans by class name (next item).
`lookupMap(Archiver.class)` does list the archivers, keyed by class name
(`org.codehaus.plexus.archiver.zip.ZipArchiver`), so hint `zip` is unavailable.
plexus-archiver master (5.0.0-SNAPSHOT) already has `new
ServiceLoaderArchiverManager()` (no DI,
`META-INF/services/org.codehaus.plexus.archivers.spi.ArchiverProvider`), and
the plugin uses it. But archivers it creates still NPE in
`addArchivedFileSet` (unpacking, every `<unpack>true`):
`AbstractArchiver.java:132` declares `@Inject private Provider<ArchiverManager>
archiverManagerProvider` (used at `:589` in `asResourceCollection`, reached
from `addArchivedFileSet` `:646`); with no container it stays null. Same NPE
for archivers taken from `lookupMap` and for `new ZipArchiver()`. 4.14.0 has
the same field (`AbstractArchiver.java:144`, use at `:673`) and no
`ServiceLoaderArchiverManager`, so the 4.x line cannot be made Sisu-free
without a backport. **Candidate fix PR for codehaus-plexus/plexus-archiver
(master)**: make `asResourceCollection` fall back to `new
ServiceLoaderArchiverManager()` when the provider is null (4 lines,
`asm-plexus-archiver-prototype.diff`; with it `addArchivedFileSet` works and
all 155 ITs' unpacking passes); better, let the ServiceLoader
providers/`ArchiverFactory` hand the manager to the archivers they create, and
add a test that unpacks through `new ServiceLoaderArchiverManager()`.
- **`javax.inject` `@Named("hint")` beans lose their hint in a Maven 4
plugin.** Probe: a `@javax.inject.Named("sisu-h")` `Handler` is in
`lookupMap(Handler.class)` under `probe.SisuHandler`, `lookup(Handler.class,
"sisu-h")` fails; `@org.apache.maven.api.di.Named("di-h")` and
`META-INF/plexus/components.xml` `role-hint`s work. The same applies to core's
`ComponentConfigurator`s (keyed
`org.codehaus.plexus.component.configurator.BasicComponentConfigurator`).
Consequence for the SPI: third-party `ContainerDescriptorHandler`s declared
with `javax.inject.@Named("hint")` cannot be selected by
`<handlerName>hint</handlerName>` any more; components.xml or `api.di.@Named`
ones can. The built-in handlers (`file-aggregator`, `metaInf-services`,
`metaInf-spring`, `plexus`) moved to `api.di.@Named`. Handlers are looked up
through `Lookup.lookupMap(ContainerDescriptorHandler.class)` at use time.
- **No Plexus component configurator.** `new BasicComponentConfigurator()`
in the plugin realm: `NoClassDefFoundError:
com.google.inject.spi.TypeConverter`; obtaining it from
`Lookup.lookupMap(ComponentConfigurator.class)` fails the same way on
provisioning (IT `massembly-345`, `archiverConfig`). Replaced by
`internal.BeanConfigurator` (setter or field per child element; String,
numbers, boolean, enum, `File`, `Path`, collections/arrays of those, `-` to
camelCase). Anything the Plexus converters did beyond that (for example nested
objects) is not supported for `archiverConfig` and handler `<configuration>`;
unverified for exotic archiver options.
- **Mojo parameter types**: `PlexusConfiguration archiverConfig` and
`Xpp3Dom` fail in v4 ("Cannot create instance of ..."); `archiverConfig` is now
`XmlNode`, its XML text is handed to the archiver configuration as before.
Descriptor model `Xpp3Dom` fields (handler `<configuration>`) are unaffected
(they are read by modello, not by the mojo configurator).
- **`${project.basedir}` default is wrong in a reactor**: it resolved to the
directory Maven was started in, not the child's (11 dependency-set ITs failed
with "Error locating assembly descriptor"). The `basedir` parameter is gone;
the value comes from the injected `Project`.
- **Dependency resolution**: `DependencyResolverRequest` needs a non-null
`pathScope`; `RESOLVE` only returns dependencies with a path type, so
`pom`/`zip`/`sar` dependencies would be dropped. The plugin uses `COLLECT` with
the project's direct dependencies (pre-filtered by scope as `classpathFilter`
did), managed dependencies and project repositories, walks the `Node` tree
itself, and resolves each artifact with `Session#resolveArtifact(artifact,
projectRepositories)` (without the repositories IT `massembly-1306` fails: the
session's repositories are not the project's). `scope=test` needs two collects
(`TEST_COMPILE` and `TEST_RUNTIME`) to cover compile, provided, runtime and
test; `system` scope rides on `MAIN_COMPILE`. `Node` has no parent link, so the
dependency trail is rebuilt during the walk.
- **`useTransitiveFiltering` / caf `actTransitively`**:
maven-common-artifact-filters 4 dropped `actTransitively` and the trail
(`PatternIncludesArtifactFilter(patterns, boolean)`), so the flag would
silently do nothing. `FilterUtils` re-creates it in two private subclasses: the
artifact is tried, then every trail element (project, ancestors) until a
pattern matches; `patternMatches` cannot tell "no match" from "negated pattern
matched", so a second filter with a trailing catch-all `*` is asked as well.
Works, but leans on caf's first-match-wins behaviour and on the protected
`patternMatches`; a `Predicate<Dependency>` with a real trail (or the flag
back) in caf would be cleaner. Tests cover include/exclude via trail.
- **Project of a dependency**: v3 built a `MavenProject` for every
dependency (and a stub `MavenProject(Model)` when that failed). v4 has
`ProjectBuilder.build(request)` from a POM file (the POM is resolved first) but
no way to create a stub `Project`; on failure the plugin continues with no
project and uses the artifact itself for `${artifact.*}` (one IT,
`including-sar-dependency`, hit that path: the sar's POM does not build).
`ProjectBuilderRequest` has no builder switch for `allowStubModel`/validation
level (v3 used minimal validation), so POMs v3 tolerated may now fail to build
and lose `${artifact.build.finalName}` / `${artifact.properties.x}`.
- **Expression surface of `${project.*}`, `${module.*}`, `${artifact.*}`
(descriptors, archiverConfig, filtering)**: v3 reflected over `MavenProject`;
v4 `Project` has no bean surface (`getBasedir()` is a `Path`, no `getBuild()`
bean tree beyond the model). The plugin evaluates against the effective `Model`
plus `basedir`, `file`, `id`. Not reproduced: `${project.artifact.*}`,
`${project.attachedArtifacts}`, `${project.compileSourceRoots}`,
`${project.artifacts}` style paths. Unverified how many real descriptors use
them.
- Project main artifact and attachments: `Project#getMainArtifact()` is
empty for pom packaging and `ArtifactManager#getPath` is the only way to a
file; pom-packaged projects are treated as having no file (as v3), otherwise
`useProjectArtifact` added the POM to the archive (IT `massembly-1022`).
Attachment files come from `ArtifactManager`, attachments are created with
`Session#createProducedArtifact(..., classifier, extension, null)` plus
`ProjectManager#attachArtifact(project, artifact, path)`; the
`attachArtifact(session, project, type, path)` default has no classifier
parameter. Replacing the main artifact file (`appendAssemblyId=false`) uses
`Session#setArtifactPath`.
- `@Mojo` has no `threadSafe` and no `requiresDependencyResolution`
attribute (only `dependencyResolutionPathScopes`, unused): resolution happens
inside the mojo, and the plugin is not marked thread-safe. `maven-plugin-tools`
4.0.0-beta-3 constructor injection of a mojo is not possible (field `@Inject`).
- `BuildContext` (plexus-build-api) is not bound in the CLI; it is looked up
optionally and skipped when absent (it only refreshed the archive for IDEs).
- Build: plexus-archiver 5.0.0-SNAPSHOT changes the `Archiver` interface
(removed deprecated methods), so `AssemblyProxyArchiver` (939 lines, implements
`Archiver`) had to drop the implementations of the removed methods; it still
compiles against 4.14.0 only because the `Archiver` methods it no longer
implements would be abstract there, i.e. it does not.
**Removed or changed tests** (nothing else deleted)
- `FilterUtilsTest.filterProjectsShouldNotRemoveProjectTransitivelyIncluded`
and `filterProjectsShouldRemoveProjectTransitivelyExcluded`: a reactor
project's main artifact has no dependency trail in production (v3 or v4); the
tests passed only because the mock returned one.
-
`ModuleSetAssemblyPhaseTest.getModuleProjectsShouldExcludeModuleAndDescendentsTransitively`:
same reason, it relied on a mocked `getDependencyTrail()`.
- `DefaultDependencyResolverTest` rewritten for the v4 resolver (mocked
`DependencyResolver`/`Session`), `AddDependencySetsTaskTest` for the v4
`ProjectBuilder`; one test added
(`getDependencySetResolutionRequirementsFiltersByScope`). Test
projects/sessions/artifacts are Mockito stubs in the new `testutils/TestStubs`.
**User-visible changes**
- Runs on Maven 4 only and needs Java 17; no 3.x support, a 3.x line must
stay for Maven 3 users.
- Parameters removed from the descriptor: `basedir`, `reactorProjects`,
`mavenSession` (all readonly). `archiverConfig` is now an `XmlNode` (same XML).
- `<archive>` is the maven-archiver 4 `MavenArchiveConfiguration`
(`manifestFile` is resolved as a `Path`).
- Third-party `ContainerDescriptorHandler`s registered with
`javax.inject.@Named("hint")` are not found by hint (see Gaps).
- `useTransitiveFiltering` behaviour is preserved by plugin code, not by the
library.
- Output of descriptors that used `${project.artifact...}`-style expressions
may differ (see Gaps).
**Improvements:** drops `javax.inject`, `sisu-maven-plugin` (Sisu index),
`maven-plugin-api`, `maven-core`, `maven-model`, `maven-model-builder`,
`maven-artifact`, `maven-resolver-api/util`, `maven-plugin-annotations`; adds
`maven-api-core`, `maven-api-di`, `maven-api-model`, `maven-api-xml`,
`maven-api-annotations` (provided). `org.eclipse.sisu.plexus` stays provided
only for the `ExpressionEvaluator` interface, `plexus-build-api` only for the
optional `BuildContext` type. No new runtime dependency. The Plexus
configurator, the PlexusContainer lookup and the reflection over `MavenProject`
are gone.
**Recommendation:** port for the Maven 4 line once plexus-archiver ships the
no-DI unpack fix (first Gap item); until then the plugin depends on an
unreleased 5.0.0 and on a patch. Two upstream asks that would remove most
hacks: (1) plexus-archiver: unpack without a JSR-330 container, and a released
`ServiceLoaderArchiverManager`; (2) Maven core: honour `javax.inject.@Named`
hints (or document that only `api.di.@Named` and components.xml keep them), and
fix `${project.basedir}` in a reactor. Keep 3.x for Maven 3.
</details>
<details><summary><b>maven-changelog-plugin</b>: blocked</summary>
Branch `agent/mvn4-api`; PR not opened yet. Status: **blocked**,
4.0.0-beta-1-SNAPSHOT, Java 17. The plugin code ports and compiles; it cannot
run, because every consumer of a report mojo is a Maven 3 class.
Verified locally: Maven 4.0.0-rc-7, JDK 21. `mvn verify` before → 23 tests,
0 failures. After → 23 tests, 19 errors, 0 failures (`ChangeLogReportTest` 15,
`DeveloperActivityReportTest` 2, `FileActivityReportTest` 2); the 4 tests that
pass do not execute a report. `-Prun-its` before → 4/4 ITs pass; after → 0/4
(whole suite, no time-box hit). Spotless clean. No test deleted.
**Concrete build errors (reporting chain)**
1. Against the released `maven-reporting-impl` 4.0.0, with only Maven 4 API
dependencies: `cannot access org.apache.maven.plugin.AbstractMojo` at
`ChangeLogReport extends AbstractMavenReport`. The released base class extends
the Maven 3 `AbstractMojo`.
2. Against the local `maven-reporting-impl` 5.0.0-SNAPSHOT port (see below):
compiles, but every unit test that executes a report fails with
`IllegalStateException: Cannot get the Maven 3 object from
org.apache.maven.impl.InternalSession...#getMavenSession()`. The ported
`AbstractMavenReport.execute()` reaches the Plexus container through
`LegacyMavenBridge` and `Session.getMavenSession()`. The impl port's own ITs
fail the same way at runtime with `A required class was missing ...
org/apache/maven/execution/MavenSession`: `maven-core` is not visible in a
plugin class realm.
3. Real build, maven-site-plugin 3.22.0 on Maven 4.0.0-rc-7, all 4 ITs:
`Failed to get report for org.apache.maven.plugins:maven-changelog-plugin:
Unable to lookup Mojo: Cannot cast
org.apache.maven.plugins.changelog.ChangeLogReport[Factory] to
org.apache.maven.plugin.Mojo`. Site plugin 3.x only accepts Maven 3 mojos as
reports.
**Snapshots consumed:** `maven-reporting-impl` 5.0.0-SNAPSHOT, built from
`maven-reporting-impl` `agent/mvn4-api` (`mvn install -DskipTests
-Dinvoker.skip=true`, installed into the local repository);
`maven-reporting-api` 4.0.0 (release).
**User-visible changes**
- Version 3.0.0-M3-SNAPSHOT → 4.0.0-beta-1-SNAPSHOT; needs Maven 4;
`<prerequisites>` follows `mavenVersion`.
- Goals and parameter names unchanged: `changelog`, `dev-activity`,
`file-activity`.
- `developers`: `List<org.apache.maven.model.Developer>` →
`List<org.apache.maven.api.model.Developer>`. The `project.developers`
expression default is gone (the Maven 4 test container cannot evaluate an
expression to a raw `List`); when unset, the mojo reads
`project.getModel().getDevelopers()`. The v4 `Developer` is immutable, so a
POM-level `<developers>` override in plugin configuration is no longer
expressible as before. Not verified under a real build because of the block
above.
- `settings` parameter (`${settings}`) removed; credentials come from
`Session.getSettings().getServers()`, matched on `host[:port]`. Users who
passed a `Settings` object in test configurations lose that hook.
- `ScmManager` is a Plexus component and v4 DI reports `No binding to
construct an instance for key ScmManager` (seen in both unit tests and the
first IT run). The mojo now obtains it with `Lookup.lookup(ScmManager.class)`
on first use; that path is unexercised in a real build because of error 3.
- `MojoExecutionException` no longer thrown (`MojoException`);
`ChangeLogReport.checkResult` is public and now declares `MojoException`.
- Test infrastructure moves to maven-plugin-testing-harness 4.0.0-beta-4,
`maven-impl`, Guice and Mockito 5; resolver 1.9.27 → 2.0.23; transport
`maven-resolver-transport-http` → `-apache`.
**Gaps**
- No Maven 4 report contract that site plugin 3.x accepts (error 3); needs a
v4 maven-site-plugin, which needs the Doxia site-tools port
(apache/maven-doxia-sitetools#701).
- No Maven 4 path from a plugin realm to the site renderer (error 2); the
reporting-impl port works around it with `MavenSession`, which is not exported.
- No v4 DI route to Sisu/Plexus components (`ScmManager`); `Lookup` is the
workaround.
**Improvements:** drops `maven-plugin-api`, `maven-core`, `maven-model`,
`maven-settings`, `maven-plugin-annotations`, `javax.inject` and
`maven-artifact` (test) from the plugin's own dependencies.
**Recommendation:** do not merge. Keep on 3.x until maven-site-plugin,
maven-reporting-impl and doxia-sitetools have v4 releases in that order; then
the remaining work here is the test-harness glue (`Lookup`, `Session` settings)
and re-running the 4 ITs. The commit is a compile-clean starting point only.
</details>
<details><summary><b>maven-checkstyle-plugin</b>: partial</summary>
Branch `agent/mvn4-api`; PR not opened yet. Status: **partial**,
4.0.0-beta-1-SNAPSHOT, Java 17. The `check` goal is ported and runs in a real
Maven 4.0.0-rc-7 build (30 ITs). The two report goals (`checkstyle`,
`checkstyle-aggregate`) are **blocked** by the reporting chain and are excluded
from the build; their sources stay in the tree.
Verified locally: Maven 4.0.0-rc-7, JDK 21. `mvn -B -ntp verify` before → 26
tests, 0 failures, 1 skipped; after → 16 tests, 0 failures, 0 skipped
(`CheckstyleReportTest` 10 run / 1 skipped removed with the reports; every
other test kept: `CheckstyleViolationCheckMojoTest` 6, `RuleUtilTest` 4,
`CheckstyleResultsTest` 2, `CheckstyleExecutorTest` 1, both
`CheckstyleReportListener*Test` 1, `ViolationTest` 1). `-Prun-its` before →
49/49 invoker ITs pass (24 min); after → 30/30 of the ITs that do not need a
report goal pass (`clean verify -Prun-its`, 4:48 min); the other 19 are
excluded with `pomExcludes` (list under Gaps). Run unexcluded, the suite was 27
of 49 on the first pass (fixes for the 3 inline-rules ITs applied afterwards,
then 30 of 30). Spotless clean. `dependency:analyze` clean.
**Report goals: can they be ported?** No, not today. Concrete errors:
1. Real compile of the unchanged `AbstractCheckstyleReport` against Maven 4
API + released `maven-reporting-impl` 4.0.0:
`AbstractCheckstyleReport.java:[64,56] cannot access
org.apache.maven.plugin.AbstractMojo` (the released base class extends the
Maven 3 `AbstractMojo`, which is not on a v4-only classpath).
2. Even with a v4 `reporting-impl` (the 5.0.0-SNAPSHOT port), site plugin
3.x on rc-7 only accepts Maven 3 mojos as reports: `Unable to lookup Mojo:
Cannot cast org.apache.maven.plugins.changelog.ChangeLogReport[Factory] to
org.apache.maven.plugin.Mojo` (proven on maven-changelog-plugin, same chain,
not re-run here). The port would also need `maven-core` types from
reporting-impl at runtime (`MavenSession`), which a plugin realm cannot see.
3. The report classes additionally use Doxia sink/i18n
(`CheckstyleReportRenderer`, 696 lines), `MavenProject` and
`MavenReportException`; all of that has to move with the chain (doxia-sitetools
→ site plugin → reporting-impl).
Excluded from compilation: `AbstractCheckstyleReport`, `CheckstyleReport`,
`CheckstyleAggregateReport`, `CheckstyleReportRenderer` (compiler `excludes` in
the pom; sources kept).
**Non-report goal**
- `check`: mojo implements `org.apache.maven.api.plugin.Mojo`; injected
`Session`, `Project`, `MojoExecution`, `Log` and the executor (`@Inject
@Named("default")`, field injection because mojo constructor injection fails in
rc-7). `MojoExecutionException`/`MojoFailureException` become `MojoException`.
- Executor (`DefaultCheckstyleExecutor`): `@Named("default")` with
`org.apache.maven.api.di`, no Sisu `@Typed`; the DI index is generated by the
annotation processor (`META-INF/maven/org.apache.maven.api.di.Inject` lists the
mojo factory and the executor).
- Source roots: `ProjectManager.getEnabledSourceRoots(project, scope,
Language.JAVA_FAMILY)`; resources: the same call with `Language.RESOURCES`,
turned into `org.apache.maven.api.model.Resource`. New helper
`exec/ProjectRoots`.
- Plugin dependency artifacts for license/config lookup (`${plugin}`
`PluginDescriptor.getArtifactMap()` in v3):
`MojoExecution.getPlugin().getDependenciesMap()` plus
`ArtifactManager.getPath(Dependency)`; proven by ITs
`MCHECKSTYLE-225-customHeader`, `-225-pluginManagement`, `-225-LICENSE.txt`,
`-219-*` (license read from a plugin-dependency jar).
- Classpath for Checkstyle (`project.getTestClasspathElements()` in v3):
`Session.resolveDependencies(project, PathScope.TEST_COMPILE | MAIN_COMPILE)`
plus the output directories. A resolution failure logs a warning and continues
with the output directories only (v3 with `requiresDependencyResolution=NONE`
never failed here).
**plexus-resources without Sisu (how `ResourceManager` was obtained)**
`DefaultCheckstyleExecutor` and `LicenseResourceManager` no longer get
`ResourceManager`/`Map<String,ResourceLoader>` injected. plexus-resources 1.4.0
is a Sisu component library but its classes are plain: `javap` of
`plexus-resources-1.4.0.jar` shows `DefaultResourceManager` has `public
DefaultResourceManager(Map<String,ResourceLoader>)` and `FileResourceLoader`,
`JarResourceLoader`, `URLResourceLoader`,
`ThreadContextClasspathResourceLoader` all have public no-arg constructors.
Their `@javax.inject.Named` values (read from the class files) are `file`
(`FileResourceLoader.ID`), `jar`, `url`, `classloader`. The executor builds
`new LinkedHashMap` with those four and passes it to `new
DefaultResourceManager(map)` or `new LicenseResourceManager(map)`. The loaders
keep search paths, so every `executeCheckstyle` call builds fresh instances
(the v3 singleton managers were reconfigured on every call). No `Lookup`, no
Sisu, no `@Named("license")` binding. `LicenseResourceManager` keeps i
ts `instanceof ThreadContextClasspathResourceLoader` filter (MCHECKSTYLE-219),
which works because the loader class is unchanged.
**User-visible changes**
- Version 3.6.1-SNAPSHOT → 4.0.0-beta-1-SNAPSHOT; needs Maven 4.0.0-rc-7;
Java 17.
- Goals: `check` and `help` only. `checkstyle:checkstyle` and
`checkstyle:checkstyle-aggregate` are gone until the reporting chain is ported;
`<reporting>` entries and `checkstyle:checkstyle checkstyle:check` command
lines break.
- `check` parameters unchanged, except: `resources` and `testResources`
(read-only, `${project.resources}`) and the injected `project`/`plugin`
parameters are no longer parameters; `checkstyleRules` is
`org.apache.maven.api.xml.XmlNode` instead of `PlexusConfiguration`;
`threadSafe` has no v4 attribute.
- The mojo no longer fails the build with the `MojoFailureException` type: a
violation failure and an execution failure are both `MojoException` (message
unchanged; build result is FAILURE either way).
- `checkstyleRules` inline config: Maven 4.0.0-rc-7 drops all attributes
when it injects an `XmlNode` parameter (`-X` shows the configuration with
`<module name="Checker">` and `(f) checkstyleRules = <module>...` without
`name`; `inlinerules`, `MCHECKSTYLE-295`, `-371` fail with `Attribute "name" is
required ... for element type "module"`). The mojo reads the node from
`MojoExecution.getConfiguration()` instead, and writes it with
`XmlService.write` (`XmlNode.toString()` is not XML). Consequence: `${...}`
expressions inside the inline rules are not evaluated (they were not with
`PlexusConfiguration` either).
- Checkstyle classpath now comes from an explicit dependency resolution, so
`check` on a module whose dependencies cannot be resolved warns instead of
silently using only the output directories.
- Test infrastructure: maven-plugin-testing-harness 3.5.1 → 4.0.0-beta-4,
plus `maven-impl`, `maven-core`, `maven-xml`, Guice 6; test configs use
`${project.basedir}` (the harness does not evaluate `${basedir}`); slf4j 1.7.36
→ 2.0.19; resolver test dependencies dropped.
- ITs edited: `MCHECKSTYLE-131`, `inlinerules`, `multi-modules`,
`multimoduleproject` ran `clean checkstyle:checkstyle checkstyle:check`; now
`clean checkstyle:check` (`check` runs the analysis itself). Their assertions
are unchanged and pass.
**Gaps**
- Report goals: see above. 19 ITs excluded in the `run-its` profile because
they call `checkstyle:checkstyle`, `site`, or bind the `checkstyle` goal:
`MCHECKSTYLE-137`, `-172`, `-193`, `-222-no-resources`, `-222-resources`,
`-222-testResources`, `-224`, `-253-jdk8`, `-332_cache-checker`, `-338`,
`-357`, `-357-with-header-override`, `-365`, `-99`,
`-99-custom-xref-test-location`, `checkstyle-goal`, `checkstyle-report`,
`minimal-pom`, `multi-modules-aggregate`. Not deleted; they pass again when the
report goals return. Their failure on the ported plugin is `Could not find goal
'checkstyle' in plugin ...:maven-checkstyle-plugin:4.0.0-beta-1-SNAPSHOT among
available goals check, help`.
- `XmlNode` parameter injection loses attributes in Maven 4.0.0-rc-7
(workaround above; a core issue).
- `org.apache.maven.api.model.Resource` is deprecated in rc-7 (javac
warning) in favour of `SourceRoot`; kept because the executor request and
`addResourceFilesToProcess` only need directory, includes and excludes.
- No v4 equivalent of `Plugin.getArtifactMap()` for transitive plugin-realm
artifacts; `getDependenciesMap()` covers the direct `<dependencies>` of the
plugin, which is what v3 code looked up.
**Improvements:** drops `maven-plugin-api`, `maven-core`, `maven-model`,
`maven-artifact`, `maven-plugin-annotations`, `javax.inject`,
`org.eclipse.sisu.plexus`, `org.eclipse.sisu.inject`, `sisu-maven-plugin`,
`animal-sniffer-maven-plugin` (Java 8 signature),
`maven-reporting-api`/`-impl`, `doxia-core`/`-sink-api`/`-integration-tools`
and `plexus-i18n` from the plugin's own dependencies; resource managers are no
longer singletons with shared search paths.
**Recommendation:** do not merge. `check` is a usable starting point and
keeps every `check` IT green on rc-7. Keep the plugin on 3.x until
maven-site-plugin, maven-reporting-impl and doxia-sitetools have v4 releases in
that order; then restore the four report classes (port `MavenProject` to
`Project`, `MavenReportException` to the v4 report contract) and re-enable the
19 ITs. Separately worth filing against Maven core: the `XmlNode` attribute
loss.
</details>
<details><summary><b>maven-dependency-plugin</b>: partial</summary>
Branch `agent/mvn4-api`; PR not opened yet. Status: **partial**,
4.0.0-beta-1-SNAPSHOT, Java 17. 25 of 29 goals ship and run on Maven
4.0.0-rc-7; `add`, `remove`, `list-repositories` and `analyze-report` are not
shipped.
Verified locally: `mvn verify`, Maven 4.0.0-rc-7, JDK 21. Unit tests before
435 run, 0 failed, 1 skipped; after 174 run, 0 failed, 0 skipped (accounting
under Gaps). spotless:check, checkstyle, RAT, enforcer and the plugin's own
`analyze-only` (strict) pass. ITs (`-Prun-its -Dinvoker.test=` subset, only
ported goals, 30 min time-box): before, 75 builds, 74 passed, 1 failed
(`unpack-custom-ear`, fails on the unchanged tree;
`purge-local-repository-bad-pom` failed once and passed on rerun) in 1534 s;
plus 19 more, 18 passed, 0 failed, 1 skipped (`analyze-exclusions-gh-1598`, the
IT excludes Maven 4 itself) in 236 s. After, 94 builds: 85 passed, 8 failed, 1
skipped (582 s), then `mdep-450-*` rerun after a fix, 2 of 2 passed. The 8
failures: `unpack-custom-ear` (same as before), `analyze-report`,
`analyze-testDependencyWithNonTestScope`, `list-repositories` (goals not
shipped), `tree-verbose`, `tree-verbose-small`, `used-dependencies`,
`mdep-450-project-with-ancestor` (fixed after tha
t run). IT subset: analyze*, build-classpath*, collect, copy*, filterunpack,
get-*, mdep-4xx..9xx for ported goals, purge-local-repository*, resolve*,
go-offline*, tree*, unpack*, used-dependencies, dependency-properties,
list-repositories, analyze-report. Not run: add-dependency, remove-dependency,
setup-custom-ear-lifecycle.
Shared snapshots consumed (built from the local branch agent/mvn4-api,
commit "Port to the Maven 4 API"): maven-dependency-tree 4.0.0-SNAPSHOT
a610f3b1ab9e01de142ae84b4363fcaa1db4ac50; maven-dependency-analyzer
2.0.0-SNAPSHOT f10337cef52a2366f4c46a685bef853a31d5484f;
maven-common-artifact-filters 4.0.0-SNAPSHOT
c2fdc406acfb36807bf1dd1f31eeecee510bb40f. Experiment only, not a dependency of
the result: maven-reporting-impl 5.0.0-SNAPSHOT
21c3da415d7ebcf965f2dc1e1c101164220cdb74. plexus-archiver stays the released
4.14.0; its `ArchiverManager` is a Sisu component that a v4 mojo cannot have
injected and the `Lookup` service does not find in the plugin realm, so
`UnpackUtil` builds `DefaultArchiverManager` by hand from the `UnArchiver`
entries of plexus-archiver's `META-INF/sisu/javax.inject.Named` (new compile
dependency `javax.inject:javax.inject:1` for `Provider`/`Named`).
**Per-goal table**
| Goal | Status | Missing API / difference |
|---|---|---|
| tree | ported | verbose output differs (dependency-tree 4 port has no
premanaged/conflict data): "(scope not updated to compile)" lost, "scope
updated from compile" added; tree-verbose ITs fail. Root node has no
dependency, so include/exclude patterns are matched against the project in the
mojo |
| analyze, analyze-only | ported | params `baseDir`, `outputDirectory`
removed (`${basedir}` does not evaluate). `analyze` forks via
`@Execute(phase="test-compile")`; the forked build does not leave reactor
siblings resolvable, so `used-dependencies` (multi-module) fails |
| analyze-dep-mgt, analyze-duplicate, analyze-exclusions | ported |
analyze-exclusions needs model `InputLocation` (present on
`Project.getModel()`); only exercised by hand, its IT skips Maven 4 |
| analyze-report | no run route | port compiles against reporting-impl
5.0.0-SNAPSHOT (source changed, excluded from compile). Running: class
`org.apache.maven.execution.MavenSession` not found in the v4 plugin realm;
with maven-core added, "A type incompatibility occurred" (two copies of core
classes). Reporting chain, not plugin code |
| copy, copy-dependencies, unpack, unpack-dependencies | ported |
`BuildContext` (m2e) gone: `skipDuringIncrementalBuild` accepted, no effect |
| resolve, list, collect, resolve-sources, sources | ported | collect uses
`DependencyResolver.flatten` (no download); "sources" classifier fixed at run
time (no `@Parameter` on setters) |
| build-classpath | ported | attach via `ProjectManager` |
| get, list-classes, properties, display-ancestors | ported | relocation and
POM download re-implemented (resolver no longer reads descriptors) |
| purge-local-repository | ported | "launched from CLI" approximated by
execution id `default-cli`; relocation/descriptor as above |
| go-offline, resolve-plugins | ported | plugin `<dependencies>` scope and
exclusions cannot reach the v4 request (resolved as compile, no exclusions) |
| render-dependencies | ported | templates see a `TemplateArtifact` bean
with the Maven 3 getters |
| list-repositories | no v4 route | `RemoteRepository` has no
mirrored-repositories or policy; IT expects "mirrored by" and
"releases+snapshots" |
| add, remove | not ported | need raw/original model and in-memory model
update (`syncInMemoryModel`); not attempted, `pom/DependencyEntry` kept |
**Public API changes**
- Every mojo implements `org.apache.maven.api.plugin.Mojo`, `@Inject`
fields, unchecked `MojoException`; Maven 3 `Artifact` replaced by
`ResolvedDependency` (new, path + coordinates) and `api.Dependency`;
`ResolverUtil`, `CopyUtil`, `UnpackUtil` are plain classes, not components;
`ArtifactItem.getArtifact()` returns `DownloadedDependency`;
filters/markers/translators take `Dependency`; `DependencyUtil` gains `getId`,
`toString`, `getDependencyConflictId`.
**Gaps**
- Resolver behaviours lost and rebuilt: POM download and relocation
(`Session.resolveArtifact`), pre-order artifact order, `Project.getParent()`
empty for repository parents, purge root-dependency scope semantics.
- plugin-tools 4.0.0-beta-3 crashes on `@Mojo(dependencyCollection = true)`,
so `requiresDependencyCollection` is dropped; `requiresDependencyResolution`,
`threadSafe` have no v4 attribute (resolved inside the mojo).
- Tests: 435 to 174. Kept/ported: utils, filters, markers, translators,
ArtifactItem, matchers, pruning visitor, ExclusionChecker, reactor filters,
TestAnalyzeDepMgt (4 of 5; `mojo()` removed), ResolverUtilTest (22 to 18,
descriptor/installer/collect cases rewritten for the v4 calls), pom/* (58,
domtrip test scope); new ResolvedDependencyTest (4), TreeSerializationTest (5,
replaces TestTreeMojo, whose mojo-discovery case is removed). Not compiled
(files remain, excluded by `testIncludes`, Maven 3 harness with
`MavenProject`/`MavenSession` stubs; ITs cover the goals):
AddDependencyMojoTest 36, RemoveDependencyMojoTest 12,
AnalyzeExclusionsMojoTest 9, GoOfflineMojoTest 9, ResolveDependenciesMojoTest
4, TestAnalyzeDuplicateMojo 2, TestBuildClasspathMojo 2, TestCollectMojo 3,
TestCopyDependenciesMojo 35 + 2: 14, TestCopyMojo 29, TestGetMojo 8,
TestIncludeExcludeUnpackDependenciesMojo 7, TestIncludeExcludeUnpackMojo 11,
TestListClassesMojo 4, TestPropertiesMojo 2, TestRenderDependencie
sMojo 2, TestResolveMojo 2, TestSkip 19, TestTreeMojo 6,
TestUnpackDependenciesMojo 27 + 2: 5, TestUnpackMojo 17.
**User-visible changes**
- Runs on Maven 4 only, Java 17; 3.x line must stay for Maven 3. Goals
`add`, `remove`, `list-repositories`, `analyze-report` absent. Parameters
`baseDir`, `outputDirectory` (analyze) removed; `skipDuringIncrementalBuild`
no-op; `render-dependencies` templates keep Maven 3 getters; tree verbose
annotations differ; `dependency:analyze` on a multi-module reactor needs
siblings already built (use `analyze-only` in the lifecycle).
**Improvements:** drops maven-core, maven-plugin-api, maven-model,
maven-artifact, maven-settings, maven-repository-metadata, maven-resolver-*,
plexus-build-api, sisu.plexus, plexus-i18n, maven-shared-utils, javax.inject
annotations build; test side drops jetty and plugin-testing-harness. Adds
maven-api-*, three shared snapshots, `javax.inject`, slf4j-api (provided).
**Recommendation:** ship the ported goals on the Maven 4 line, keep 3.x for
Maven 3. Before a real PR: fix the dependency-tree verbose data, decide
`@Execute` reactor behaviour upstream in Maven, file a plugin-tools issue for
`dependencyCollection`, and port add/remove (route exists, unattempted).
</details>
--
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]
