chrned opened a new issue, #13597:
URL: https://github.com/apache/maven/issues/13597
On Maven 3.10.0, a core extension, loaded from `.mvn/extensions.xml`, that
resolves project dependencies in
`AbstractMavenLifecycleParticipant.afterProjectsRead` fails:
```
java.lang.IllegalArgumentException: Unknown collector impl: 'bf', known
implementations are []
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:77)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:376)
at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
(DefaultProjectDependenciesResolver.java:153)
...
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:229)
```
The same extension works on Maven 3.9.x. It also works on 3.10.0 when loaded
with `-Dmaven.ext.class.path` instead of `.mvn/extensions.xml`. The build's own
dependency resolution, later in the same run, is not affected.
Minimal extension, built against `maven-core:3.9.16` (provided) with a
`META-INF/sisu/javax.inject.Named` file listing `probe.ResolveProbe`:
```java
package probe;
import javax.inject.Inject;
import javax.inject.Named;
import javax.inject.Singleton;
import org.apache.maven.AbstractMavenLifecycleParticipant;
import org.apache.maven.execution.MavenSession;
import org.apache.maven.project.DefaultDependencyResolutionRequest;
import org.apache.maven.project.MavenProject;
import org.apache.maven.project.ProjectDependenciesResolver;
@Named("resolve-probe")
@Singleton
public class ResolveProbe extends AbstractMavenLifecycleParticipant {
private final ProjectDependenciesResolver resolver;
@Inject
public ResolveProbe(ProjectDependenciesResolver resolver) {
this.resolver = resolver;
}
@Override
public void afterProjectsRead(MavenSession session) {
for (MavenProject project : session.getProjects()) {
try {
resolver.resolve(new
DefaultDependencyResolutionRequest(project, session.getRepositorySession()));
System.out.println("PROBE ok " + project.getArtifactId());
} catch (Exception e) {
System.out.println("PROBE fail " + project.getArtifactId() +
": " + e);
}
}
}
}
```
Steps:
1. Install the extension, then list it in `.mvn/extensions.xml` of any
project with one dependency.
2. Run `mvn validate`.
Results:
| Maven | Loaded through | Result |
| --- | --- | --- |
| 3.9.11 | `.mvn/extensions.xml` | ok |
| 3.10.0 | `.mvn/extensions.xml` | fail, as above |
| 3.10.0 | `-Dmaven.ext.class.path` | ok |
| 3.10.0 with Sisu 1.0.0 jars swapped into `lib/` | `.mvn/extensions.xml` |
ok |
| 3.10.0 with the fix below | `.mvn/extensions.xml` | ok |
Inside the failing call, the collector's injected `Map<String,
DependencyCollectorDelegate>` reads `[bf, df]` on 3.9.11 and `[]` on 3.10.0.
Cause: Maven 3.10.0 moved to Sisu 1.1.0 (#12547). Sisu 1.1.0 filters JSR330
beans by realm visibility of the thread context class loader
(eclipse-sisu/sisu-project#266). With core extensions present, from
`.mvn/extensions.xml` or `-Dmaven.ext.class.path`, the container realm is
`maven.ext`, and container beans are sourced from it
(`MavenCli.setupContainerRealm`). An extension from `.mvn/extensions.xml` gets
a realm of its own, and `DefaultMaven` calls `afterProjectsRead` with that
realm as TCCL. `maven.ext` is not visible from it. So every container bean
disappears from lazily evaluated injected collections, here the resolver's
collector delegates. An extension on `-Dmaven.ext.class.path` is loaded into
`maven.ext` itself, so its TCCL is the container realm, which is why that row
of the table works.
The same visibility gap already affects Plexus components on Maven 3.9.x.
Seen from a core extension's realm there, the lifecycle mappings read as empty,
so an extension that builds an effective model with plugin processing during
`afterProjectsRead` gets `Unknown packaging: jar`. 3.10.0 widens it to JSR330
components such as the resolver's.
#12554 found and fixed exactly this on master, in
`PlexusContainerCapsuleFactory`, by importing the container realm into each
extension realm. The 3.x launcher, `maven-embedder`'s
`MavenCli.setupContainerRealm`, did not get the same change. It is missing in
3.10.0 and on `maven-3.10.x` (`0cc6223a07`).
Proposed fix, in
`maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java`,
`setupContainerRealm`, inside the loop over core extensions:
```java
for (CoreExtensionEntry entry : reverse(extensions)) {
Set<String> exportedPackages = entry.getExportedPackages();
ClassRealm realm = entry.getClassRealm();
for (String exportedPackage : exportedPackages) {
extRealm.importFrom(realm, exportedPackage);
}
if (exportedPackages.isEmpty()) {
// sisu uses realm imports to establish component
visibility
extRealm.importFrom(realm, realm.getId());
}
// Make the container realm visible from the extension realm
(as #12554 did for Maven 4)
realm.importFrom(extRealm, extRealm.getId());
}
```
With this change compiled into a copy of the 3.10.0 distribution, the
extension above and Scalpel 0.4.3 both work, with Sisu 1.1.0 kept.
Versions: Maven 3.10.0, Sisu 1.1.0, Resolver 2.0.24, Java 25, macOS 26
(arm64).
References:
- Sisu filtering: https://github.com/eclipse-sisu/sisu-project/pull/266, and
`RealmManager.visibilityPredicate` at `releases/1.1.0` (`202effd6`),
`org.eclipse.sisu.plexus/src/main/java/org/eclipse/sisu/plexus/RealmManager.java:92-101`
- Maven 4 fix: https://github.com/apache/maven/pull/12554 (`6e8fa181d4`)
- 3.10.0 container realm set-up:
`maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java:884-912` at
`c43a36b8d6`
- TCCL during `afterProjectsRead`:
`maven-core/src/main/java/org/apache/maven/DefaultMaven.java:224-234` at
`c43a36b8d6`
--
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]
