Quarkus Maven Plugin fails on Maven 4

[lprimak]

Describe the bug

mvn package using latest Maven 4 alpha fails:

[INFO] --- quarkus:3.6.1:generate-code-tests (default) @ command-mode-quickstart ---
[INFO] --------------------------------------------------------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] --------------------------------------------------------------------------------------------------------------------------
[INFO] Total time:  39.536 s (Wall Clock)
[INFO] Finished at: 2023-12-08T15:10:10-06:00
[INFO] --------------------------------------------------------------------------------------------------------------------------
[ERROR] Failed to execute goal io.quarkus.platform:quarkus-maven-plugin:3.6.1:generate-code-tests (default) on project command-mode-quickstart: Quarkus code generation phase has failed: No valid constructor found on class org.apache.maven.internal.impl.DefaultTransport -> [Help 1]

Expected behavior

Maven build succeeds

Actual behavior

Maven build fails

How to Reproduce?

• Download Maven 4 alpha, or use sdkman
• Create a Quarkus sample app (any)
• Try to build

Output of uname -a or ver

Any

Output of java -version

21.0.1

Quarkus version or git rev

3.6.1

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 4.0.0-alpha-8

Additional information

No response

[quarkus-bot]

/cc @quarkusio/devtools (maven)

[gastaldi]

Quarkus is not compatible with Maven 4 Alpha. Unless someone from the community jumps in, this will only be done when Maven 4 goes GA

[lprimak]

Understood, but I think this issue should remain open since it will surely apply to maven 4 GA as well

[gastaldi]

I appreciate the issue, but because a lot may change until GA is out, I'd prefer to reopen only when the release happens.

[maxandersen]

It makes very much sense we have issue open for maven 4.

Even if not GA.

We recommend our users and extensions writers to try out releases early too.

Let's have this issue open for comments/work around maven 4 and if some makes an attempt to have the plugin work on 4 that is possible to find in one place rather than having it reported every time a new maven 4 build is available.

[starksm64]

So I took a look at just building quarkus with Maven 4.0.0.alpha8 and the devtools/cli module fails to build with the same exception. Looking into the problem, it stems from the io.smallrye.beanbag.sisu.Sisu class not finding a default constructor for the org.apache.maven.internal.impl.DefaultTransport class. There is a big update in the usage of the SISU framework in maven 4, and many beans given in the maven-core-4.0.0-alpha-8.jar META-INF/sisu/javax.inject.Named file do not have default constructors, but are used by a provider type, for example, classorg.apache.maven.internal.impl.DefaultTransportProvider. This class does not implement the injection javax.inject.Provider interface though, so I'm not sure how DefaultTransport is supposed to be used by the SISU framework. I'm not familiar with it, so that would need to be investigated.

There is a big change in SISU versions between smallrye-beanbag-sisu(0.3.5) vs maven-core(0.9.0.M2)

Useful repo links:
https://github.com/smallrye/smallrye-beanbag.git
https://github.com/eclipse/sisu.inject
https://github.com/eclipse/sisu.mojos
https://github.com/apache/maven.git

and here is the exception trace for the failing cli build:

Caused by: java.lang.RuntimeException: No valid constructor found on class org.apache.maven.internal.impl.DefaultTransport
    at io.smallrye.beanbag.sisu.Sisu.findConstructor (Sisu.java:887)
    at io.smallrye.beanbag.sisu.Sisu.addClass (Sisu.java:562)
    at io.smallrye.beanbag.sisu.Sisu.addClassLoader (Sisu.java:91)
    at io.smallrye.beanbag.maven.MavenFactory.<init> (MavenFactory.java:67)
    at io.smallrye.beanbag.maven.MavenFactory.create (MavenFactory.java:92)
    at io.quarkus.maven.components.QuarkusWorkspaceProvider$1.configureMavenFactory (QuarkusWorkspaceProvider.java:88)
    at io.quarkus.bootstrap.resolver.maven.BootstrapMavenContext.initRepoSystemAndManager (BootstrapMavenContext.java:860)
    at io.quarkus.bootstrap.resolver.maven.BootstrapMavenContext.getRepositorySystem (BootstrapMavenContext.java:276)
    at io.quarkus.bootstrap.resolver.maven.MavenArtifactResolver.<init> (MavenArtifactResolver.java:114)
    at io.quarkus.maven.components.QuarkusWorkspaceProvider.createArtifactResolver (QuarkusWorkspaceProvider.java:115)
    at io.quarkus.maven.QuarkusBootstrapProvider$QuarkusMavenAppBootstrap.artifactResolver (QuarkusBootstrapProvider.java:181)
    at io.quarkus.maven.QuarkusBootstrapProvider$QuarkusMavenAppBootstrap.doBootstrap (QuarkusBootstrapProvider.java:207)
    at io.quarkus.maven.QuarkusBootstrapProvider$QuarkusMavenAppBootstrap.bootstrapApplication (QuarkusBootstrapProvider.java:351)
    at io.quarkus.maven.QuarkusBootstrapProvider.bootstrapApplication (QuarkusBootstrapProvider.java:128)
    at io.quarkus.maven.QuarkusBootstrapMojo.bootstrapApplication (QuarkusBootstrapMojo.java:296)
    at io.quarkus.maven.GenerateCodeMojo.generateCode (GenerateCodeMojo.java:79)
    at io.quarkus.maven.GenerateCodeTestsMojo.doExecute (GenerateCodeTestsMojo.java:13)
    at io.quarkus.maven.QuarkusBootstrapMojo.execute (QuarkusBootstrapMojo.java:171)

[cstamas]

Will take a peek, but in general codebase moved away from def ctor (old plexus di container limitation) to ctor injection.

[aloubyansky]

I guess we should switch to maven-resolver-supplier from beanbag.

[cstamas]

Wrong, m-r-s is replacement for s-l (ServiceLocator), and allows for Resolver use only outside of Maven runtime. What you need is MIMA (that allows reusable Resolver code that runs inside and outside of Maven). Last obstacle for Quarkus use of MIMA is this issue: maveniverse/mima#94 (to expose RRM)

Also, here is an example that showcases this feature:
https://github.com/maveniverse/toolbox