Issue to execute JNoSQL with Helidon version MP 2.4.1

Environment Details

• Helidon Version: 2.4.1
• Helidon SE or Helidon MP: Helidon MP
• JDK version: Java 11 or Java 17
• OS: Linux
• Docker version (if applicable):

---

Problem Description

I have an issue executing JNoSQL with Helidon version 2.4.1 or higher.

I created a project from either Microprofiler Starter or Maven Architypes and then add these dependencies:

      <dependency>
            <groupId>org.eclipse.jnosql.mapping</groupId>
            <artifactId>mapping-document</artifactId>
            <version>${jakarta.nosql.version}</version>
        </dependency>
        <dependency>
            <groupId>org.eclipse.jnosql.communication</groupId>
            <artifactId>mongodb-driver</artifactId>
            <version>${jakarta.nosql.version}</version>
        </dependency>

I expected to work such as in the previous version, 1.4, however, it stopped working.

I have those projects where both run with extension and only one works, however, both are using the same extension event: ProcessAnnotatedType

https://github.com/architects4j/helidon-challange-skeleton

This project works fine on Java SE or with Payara.

[tjquinno]

@otaviojava Some more information on why adding the Jackson dependency helps…

As you have no doubt noticed, Helidon’s OpenAPI support layers on some SmallRye OpenAPI components. Although SmallRye defaults to using Jackson, it also permits callers to provide their own AnnotationScannerExtension to do parsing however they want, using whatever libraries they want. Helidon does just that.

Your use case has revealed a place in SmallRye’s code that uses Jackson even if the caller provides the extension.

I have opened https://github.com/smallrye/smallrye-open-api/issues/1161 about this.

As you’ve done, adding Jackson yourself to the dependencies sidesteps this problem for your Helidon app.

[ljnelson]

When the project is built, the mapping-document-1.0.0-b4.jar that ends up in target/libs appears to come from a different project than https://github.com/eclipse/jnosql/blob/1.0.0-b4/mapping/mapping-document/pom.xml.

The mapping-document-1.0.0-b4.jar that is in target/libs comes from this project: https://github.com/eclipse-ee4j/nosql/blob/1.0.0-b4/api/mapping/mapping-document/pom.xml#L27

This jakarta.nosql.mapping:mapping-document artifact does not contain a class named org.eclipse.jnosql.mapping.document.spi.DocumentExtension. In fact it does not contain any portable extensions: https://github.com/eclipse-ee4j/nosql/tree/1.0.0-b4/api/mapping/mapping-document/src/main/java/jakarta/nosql/mapping/document

The root cause appears to be that there are two jar files that end up having the same name that contain entirely different things.

If for some reason you need both of these identically-named jars that are from different projects, you can change your usage of the maven-dependency-plugin’s copy-dependencies goal to ensure that one of these jar files gets named differently when it ends up in target/libs. You can see how Helidon defines this copy-libs execution here.

A quick solution to illustrate what I’m talking about: if you pass -Dmdep.prependGroupId=true to your Maven build, you’ll see new dependencies in target/libs. Please note this is not a full solution, since the Class-Path header in the target/products.jar will not be adjusted accordingly, but it at least should show you a path forward.