Making maven-core to work with jakarta namespace

[Mario Fusco]

Hi all,

I'm in the process of making Drools and Kogito ready for Quarkus 3, trying to align them with the new set of dependencies used by Quarkus 3 and of course with the jakarta namespace.

Related to this, I bumped into a problem related with our use of maven-core and the other transitive dependencies [1] it brings in. In particular maven-core relies on the eclipse:sisu-plexus dependency injection framework to wire together its components that is still using the old javax namespace and seems not to have any plan to migrate to the jakarta one in a reasonable future. For this reason when I try to run our tests against an environment importing the jakarta namespace we get tons of exceptions like the one in [2].

I believe (correct me if I'm wrong) that also Quarkus needs to resolve programmatically, in some way, the dependencies of the project of a user and for that it should use maven-core in a similar way to what we do. If so, I guess that you may have also bumped into my same problem and possibly found a clever way to solve or workaround it? If so could you please give me some hint on what you did in this regard?

An alternative that I'm evaluating at the moment is giving a try to Jeka, that seems to have specific features to address a similar problem, but I'm a bit reluctant in adding another, potentially huge, dependency and however following this path would require a quite extensive rewriting of all our maven integration layer that I can very hardly afford in this period. Do you have any experience with this library?

Thanks in advance for any help or suggestion,

Mario

-----------------

[1]

[INFO] +- org.apache.maven:maven-core:jar:3.8.6:compile
[INFO] |  +- org.apache.maven:maven-model:jar:3.8.6:provided
[INFO] |  +- org.apache.maven:maven-settings:jar:3.8.6:compile
[INFO] |  +- org.apache.maven:maven-settings-builder:jar:3.8.6:compile
[INFO] |  |  \- org.codehaus.plexus:plexus-sec-dispatcher:jar:2.0:compile
[INFO] |  |     \- org.codehaus.plexus:plexus-cipher:jar:2.0:compile
[INFO] |  +- org.apache.maven:maven-builder-support:jar:3.8.6:compile
[INFO] |  +- org.apache.maven:maven-repository-metadata:jar:3.8.6:compile
[INFO] |  +- org.apache.maven:maven-artifact:jar:3.8.6:compile
[INFO] |  +- org.apache.maven:maven-plugin-api:jar:3.8.6:compile
[INFO] |  +- org.apache.maven:maven-model-builder:jar:3.8.6:compile
[INFO] |  +- org.apache.maven:maven-resolver-provider:jar:3.8.6:compile
[INFO] |  +- org.apache.maven.resolver:maven-resolver-impl:jar:1.7.3:compile
[INFO] |  |  \- org.apache.maven.resolver:maven-resolver-named-locks:jar:1.7.3:compile
[INFO] |  +- org.apache.maven.resolver:maven-resolver-api:jar:1.7.3:compile
[INFO] |  +- org.apache.maven.resolver:maven-resolver-spi:jar:1.7.3:compile
[INFO] |  +- org.apache.maven.resolver:maven-resolver-util:jar:1.6.3:compile
[INFO] |  +- org.apache.maven.shared:maven-shared-utils:jar:3.3.4:compile
[INFO] |  +- org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.3.5:compile
[INFO] |  +- org.eclipse.sisu:org.eclipse.sisu.inject:jar:0.3.5:compile
[INFO] |  +- org.codehaus.plexus:plexus-utils:jar:3.3.1:compile
[INFO] |  +- org.codehaus.plexus:plexus-classworlds:jar:2.6.0:compile
[INFO] |  +- org.codehaus.plexus:plexus-interpolation:jar:1.26:compile
[INFO] |  +- org.codehaus.plexus:plexus-component-annotations:jar:2.1.0:compile
[INFO] |  \- org.apache.commons:commons-lang3:jar:3.12.0:compile

[2]

[2023-03-10T16:37:27.245Z] java.lang.NoClassDefFoundError: javax/inject/Provider
[2023-03-10T16:37:27.245Z] at org.kie.maven.integration.embedder.MavenEmbedderUtils.buildPlexusContainer(MavenEmbedderUtils.java:160)
[2023-03-10T16:37:27.245Z] at org.kie.maven.integration.embedder.MavenEmbedderUtils.buildPlexusContainer(MavenEmbedderUtils.java:134)
[2023-03-10T16:37:27.245Z] at org.kie.maven.integration.embedder.PlexusComponentProvider.<init>(PlexusComponentProvider.java:37)
[2023-03-10T16:37:27.245Z] at org.kie.maven.integration.embedder.MavenEmbedderUtils.buildComponentProvider(MavenEmbedderUtils.java:50)
[2023-03-10T16:37:27.245Z] at org.kie.maven.integration.embedder.MavenEmbedder.<init>(MavenEmbedder.java:91)
[2023-03-10T16:37:27.245Z] at org.kie.maven.integration.embedder.MavenEmbedder.<init>(MavenEmbedder.java:85)
[2023-03-10T16:37:27.245Z] at org.kie.maven.integration.embedder.MavenProjectLoader.newMavenEmbedder(MavenProjectLoader.java:148)
[2023-03-10T16:37:27.245Z] at org.kie.maven.integration.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:90)
[2023-03-10T16:37:27.245Z] at org.kie.maven.integration.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:84)
[2023-03-10T16:37:27.245Z] at org.kie.maven.integration.MavenPomModelGenerator.parse(MavenPomModelGenerator.java:34)
[2023-03-10T16:37:27.245Z] at org.kie.util.maven.support.PomModel$Parser.parse(PomModel.java:110)

[2023-03-10T16:37:27.246Z] Caused by: java.lang.ClassNotFoundException: javax.inject.Provider
[2023-03-10T16:37:27.246Z] at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
[2023-03-10T16:37:27.246Z] at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
[2023-03-10T16:37:27.246Z] at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
[2023-03-10T16:37:27.246Z] ... 60 more

[Guillaume Smet]

Hi Mario,

On Fri, Mar 17, 2023 at 4:06 PM Mario Fusco <mfu...@redhat.com> wrote:

I believe (correct me if I'm wrong) that also Quarkus needs to resolve programmatically, in some way, the dependencies of the project of a user and for that it should use maven-core in a similar way to what we do. If so, I guess that you may have also bumped into my same problem and possibly found a clever way to solve or workaround it? If so could you please give me some hint on what you did in this regard?

I can confirm we bumped into it. I wouldn't call our current solution clever :).

For now we are allowing the old javax.inject:javax.inject dependency in the classpath for the Maven resolver to work.

The main problem we have with this solution is that it pollutes the test classpath.

--

Guillaume

[Mario Fusco]

On Fri, Mar 17, 2023 at 5:05 PM Guillaume Smet <guillau...@gmail.com> wrote:

Hi Mario,

Hi Guillaume, and thanks for the prompt reply.

For now we are allowing the old javax.inject:javax.inject dependency in the classpath for the Maven resolver to work.

This is also an option that I was considering, even if of course I would prefer to avoid it. Anyway, if Quarkus is following this path, I guess it won't be that bad if we do the same at this point.

 

The main problem we have with this solution is that it pollutes the test classpath.

Why do you say that it pollutes only the test classpath? Don't you need the maven resolution at runtime?

Thanks for clarification,

Mario

 

--

Guillaume

[Sanne Grinovero]

Maven is used to build the applications, but it's not included in the final application.

 

Thanks for clarification,

Mario

 

--

Guillaume

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CALO%3D_Z77HX%2BmcRXmHFLYOWvefpz1kVCKQoqfxtWn2dnKNDOqGA%40mail.gmail.com.

[Guillaume Smet]

On Fri, Mar 17, 2023 at 5:23 PM Sanne Grinovero <sa...@hibernate.org> wrote:

On Fri, 17 Mar 2023 at 16:16, Mario Fusco <mfu...@redhat.com> wrote:

Why do you say that it pollutes only the test classpath? Don't you need the maven resolution at runtime?

Maven is used to build the applications, but it's not included in the final application.

Exactly.

And it pollutes the test classpath because we need JUnit to be able to bootstrap the application (which requires the Maven resolver).

I know Alexey was working in this area but IIRC it was complicated and for now we don't have a better solution.