Mark the Quarkus dependency as provided

[roguexz]

Hi Folks. Thank you for setting this project up. I took it for a spin and have a few suggestions,

• Can you make the Quarkus dependency as provided instead of making it pull the dependencies?
  • I created an app on the LTS bundle and was surprised to see higher version dependencies being pulled in because of the way this module's dependencies are configured
• I ran into classpath issues when writing my test cases
  • I had to write a custom ClassScanner that performed the class-lookup using Jandex
  • I am going to assume that you have plans of building something similar as a build-time item ... just wanted to let you know that it is needed

Will add to the list as I explore it further.

Thank you again for this project 😃

[gsmet]

Hi,

I created an app on the LTS bundle and was surprised to see higher version dependencies being pulled in because of the way this module's dependencies are configured

This shouldn't be an issue if you use the Quarkus BOM.
Dependencies shouldn't be marked as provided as otherwise you don't know what you need.

[roguexz]

@gsmet - totally agree. I am using the BOM version of the parent. But I am on 3.20.1 and this repository is currently pulling in 3.23.3

The root pom for this repository does not include the project modules as dependencies .. so I am unable to import the parent (quarkus-jnosql-parent) as a BOM and control the version properties either.

Is there a BOM for this project that I can import instead?

[dearrudam]

Hey @roguexz , thanks for contribute to this project! What Quarkus JNoSQL Database extension are you trying to use?

[roguexz]

@dearrudam

1. I am using the Arango-db module
2. I am using this in a Gradle based project
3. My project was relying on the Quarkus LTS version 3.20.1, but I had to upgrade it to 3.23.3 to match the dependencies that the Arango module was pulling

I also noticed that the @Repository references are not getting resolved. Not sure why ... but I can live without it for now - I can use the DocumentTemplate objects for now.

It would nice if I can pull in a BOM dependency for the Arango module so I can configure the Quarkus.version property.

[dearrudam]

@roguexz

The Quarkus JNoSQL Extensions are using the annotation processor provided by the org.eclipse.jnosql.lite:mapping-lite-processor:1.1.8 dependency. This dependency is automatically included when you add any Quarkus JNoSQL extension to your project.

This annotation processor is responsible to generate all the required implementation classes that will be used by the CDI during AOT compilation.

I often use Maven instead Gradle, and when we use Java 21 or above, it's necessary to explicitly set the<proc> configuration property to enable/force the annotation processing, as documented here: https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#proc .

Maybe you should do something similar in Gradle. Try to enable the annotation processors execution by passing the -proc:full to the compiler used by Gradle, like below:

Groovy DSL (build.gradle):

tasks.withType(JavaCompile).configureEach {
    options.compilerArgs += ['-proc:full']
}

Or

Kotlin DSL (build.gradle.kts):

tasks.withType<JavaCompile>().configureEach {
    options.compilerArgs.add("-proc:full")
}

Please give it a try and let us know if it works.

[roguexz]

@dearrudam - That is useful information. Adding to the compileArgs didn't work ... but I can spend time on it later as well. As I mentioned earlier, that is not a deal-breaker. I can debug it with this information.

If you folks can solve for the ability to control the Quarkus version as part of the BOM import, that would be really helpful.

Let me know if you need a hand with addressing this request.

[dearrudam]

@roguexz , could you create a sample code, put on github, just to let me learn more about your scenario? ... I'm sure this scenario is a valuable one to solve...

[dearrudam]

Hi @roguexz, I hope you're doing well!

We've just released the quarkus-jnosql-arangodb:3.4.7, so, please, check this out and let us know if it can solve your issue.

Thanks

[roguexz]

@dearrudam - I made some progress on this one.

• I had to explicitly add the mapping-lite-processor to the annotationProcessor dependency-scope.
• the code gen worked, however the test cases fail, i.e., the runtime is failing with ambiguous dependencies,

[1] Ambiguous dependencies for type org.eclipse.jnosql.mapping.metadata.EntitiesMetadata and qualifiers [@Default]
	- injection target: org.eclipse.jnosql.mapping.keyvalue.DefaultKeyValueEntityConverter#entities
	- declared on CLASS bean [types=[org.eclipse.jnosql.mapping.keyvalue.KeyValueEntityConverter, org.eclipse.jnosql.mapping.keyvalue.DefaultKeyValueEntityConverter, java.lang.Object], qualifiers=[@Default, @Any], target=org.eclipse.jnosql.mapping.keyvalue.DefaultKeyValueEntityConverter]
	- available beans:
		- CLASS bean [types=[org.eclipse.jnosql.lite.mapping.metadata.LiteEntitiesMetadata, org.eclipse.jnosql.mapping.metadata.EntitiesMetadata, java.lang.Object], qualifiers=[@Default, @Any], target=org.eclipse.jnosql.lite.mapping.metadata.LiteEntitiesMetadata]
		- CLASS bean [types=[org.eclipse.jnosql.mapping.reflection.DefaultEntitiesMetadata, org.eclipse.jnosql.mapping.metadata.EntitiesMetadata, java.lang.Object], qualifiers=[@Default, @Any], target=org.eclipse.jnosql.mapping.reflection.DefaultEntitiesMetadata]
[2] Ambiguous dependencies for type org.eclipse.jnosql.mapping.metadata.EntitiesMetadata and qualifiers [@Default]

I will try to create a test case for it and share.