Problems running CDI-lite TCK tests using byte code transformed dependencies #18690
Labels
area/arc
Issue related to ARC (dependency injection)
Comments
|
The solution that we have used in other contexts is to switch to independent artifactids, so that each can have its own dep specification. An example for hibernate is here: https://github.com/hibernate/hibernate-orm/blob/main/hibernate-core-jakarta/hibernate-core-jakarta.gradle. Although it's gradle based. /cc @Sanne @radcortez |
|
Closing this issue as CDI Lite TCK compatibility will be checked once Quarkus moves to EE 10 (for which there is currently nightly transformed branch). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
This is more of a note to track potential issues with EE9+ support prior to actually updating the Quarkus dependencies to the EE9+ jarkata.* package APIs.
Following the approach that Wildfly has taken for its EE9 preview to transform the artifacts with EE8 dependencies into EE9 dependencies using byte code transformation using the eclipse transformer, I created a TCK runner project to test the Quarkus ArC implementation against an early candidate of the EE10 CDI-lite TCK.
That project uses versions of the io.quarkus:quarkus-arc dependencies that have been transformed into artifacts with an ee9 qualifier. The mvn dependency:tree of the project is the following:
The key dependency to highlight is that io.quarkus:quarkus-arc-deployment has been transformed into io.quarkus:quarkus-arc-deployment:ee9 and that is has a dependency on io.quarkus:quarkus-arc:ee9. The transformation has also updated the io.quarkus:quarkus-arc-deployment:ee9 artifact to include an updated META-INF/quarkus-extension.properties file that points to the transformed deployment-artifact io.quarkus:quarkus-arc-deployment:ee9:
What appears to be happening is that the default maven resolver is going out to the location for the io.quarkus:quarkus-arc-deployment:ee9 artifact, and reading the pom.xml file for the io.quarkus:quarkus-arc-deployment artifact since both artifacts reside in the same io.quarkus/quarkus-arc-deployment/ee9/999-SNAPSHOT directory. It is not expecting that the ee9 qualified jar artifact has different dependencies from the standard jar artifact. Arguably it is a misuse of the qualifier mechanism to provide an alternative jar artifact.
The workaround I am looking at next is to produce proper distinct io.quarkus:quarkus-arc-ee9, io.quarkus:quarkus-arc-deployment-ee9, etc. to avoid relying on the qualifier approach.
Expected behavior
The resolved runtime artifact for io.quarkus:quarkus-arc-deployment:ee9:999-SNAPSHOT should be seen to be io.quarkus:quarkus-arc:jar:ee9:999-SNAPSHOT, the same as it is seen when running
mvn depedency:treeActual behavior
[ERROR] org.jboss.cdi.tck.tests.implementation.builtin.metadata.broken.typeparam.interceptor.InterceptedBeanTypeParamConstructorTest.arquillianBeforeClass Time elapsed: 1.233 s <<< FAILURE!
org.jboss.arquillian.container.spi.client.container.DeploymentException: Unable to start the runtime runner
Caused by: io.quarkus.bootstrap.BootstrapException: Failed to create the application model for io.quarkus.arc.tck:arc-tck-runner::jar:1.0.0-SNAPSHOT
Caused by: io.quarkus.bootstrap.resolver.AppModelResolverException: Failed to inject extension deployment dependencies for io.quarkus.arc.tck:arc-tck-runner:jar:1.0.0-SNAPSHOT
Caused by: io.quarkus.bootstrap.BootstrapDependencyProcessingException: Quarkus extension deployment artifact io.quarkus:quarkus-arc-deployment:ee9:999-SNAPSHOT does not appear to depend on the corresponding runtime artifact io.quarkus:quarkus-arc:jar:ee9:999-SNAPSHOT
How to Reproduce?
TBD: The code that illustrates this is currently in several forks of related projects and not in a shape that it can be cloned and tested. If it is worthwhile to pursue this approach I'll pull those together.
Output of
uname -aorverNo response
Output of
java -versionNo response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
No response
Build tool (ie. output of
mvnw --versionorgradlew --version)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: