Gradle 1.7.0.CR1 regression: Gradle project does not work with test-fixtures plugin anymore

[asodja]

Describe the bug
In #10327 I was directed to use java-test-fixtures plugin for reused test resources. I am happily using it now. Unfortunately with 1.7.0.CR1 this stopped working. Reproducer can be found here: https://github.com/asodja/quarkus-test-fixtures-reproducer.

When running tests inside IDE (with Intellij Runner) I get:

java.lang.RuntimeException: java.io.UncheckedIOException: Error while reading file as JAR: /Users/anzes/prototype-dev/quarkus-test-fixtures-reproducible/build/libs/quarkus-test-fixtures-reproducible-my-version.jar
	at io.quarkus.test.junit.QuarkusTestExtension.throwBootFailureException(QuarkusTestExtension.java:508)
	at io.quarkus.test.junit.QuarkusTestExtension.beforeEach(QuarkusTestExtension.java:358)
...
Caused by: java.io.FileNotFoundException: /Users/anzes/prototype-dev/quarkus-test-fixtures-reproducible/build/libs/quarkus-test-fixtures-reproducible-my-version.jar (No such file or directory)
	at java.util.zip.ZipFile.open(Native Method)
	at java.util.zip.ZipFile.<init>(ZipFile.java:225)
...

And when I run gradle test from terminal I get:

MyResourceTest > testTestFixtures() FAILED
    java.lang.LinkageError: loader constraint violation: loader (instance of io/quarkus/bootstrap/classloading/QuarkusClassLoader) previously initiated loading for a different type with name "org/my/group/MyService"
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
        at io.quarkus.bootstrap.classloading.QuarkusClassLoader.loadClass(QuarkusClassLoader.java:420)
        at io.quarkus.bootstrap.classloading.QuarkusClassLoader.loadClass(QuarkusClassLoader.java:363)
        at org.my.group.MyResourceTest.testTestFixtures(MyResourceTest.java:18)

Of course if I do gradle build and then run inside IntelliJ I get the same error as with gradle test, since jar is present in build directory.

Expected behavior
Test works and passes, no exception is thrown.

Actual behavior
Exception is thrown, test fails.

To Reproduce
Steps to reproduce the behavior:

1. git clone [email protected]:asodja/quarkus-test-fixtures-reproducer.git
2. Open in IntellIj and set Gradle: Build and run using: IntelliJ IDEA and Run tests using: IntelliJ IDEA
3. Run MyResourceTest, it fails
4. open terminal and run gradle test, it also fails
5. Set version of Quarkus to 1.6.1.Final
6. run gradle test again, it passes

Environment (please complete the following information):

• Output of uname -a or ver: MacBook Pro, Darwin Kernel Version 19.5.0
• Output of java -version: openjdk version "1.8.0_242"
• Quarkus version: 1.7.0.CR1
• Build tool: Gradle 6.5.1

---

Off topic, thank you for implementing #8737. As I follow there is still some work to do, like model caching etc, to have speed of running maven project from Intellij. But it looks like the first big step is done. Using IntelliJ runner really makes a difference when dealing with big projects, since Gradle initialization can be slow.

[quarkusbot]

/cc @quarkusio/devtools, @glefloch

[glefloch]

Thanks for reporting, the test-fixtures dependency does not seem to be available in the test configuration. We don't scan the test-fixture configuration yet. I will add it and use your reproducer to create an integration test.

[gsmet]

@glefloch as it's a regression, it would be nice to get this fixed for the Final, which means to merge a fix before Thursday evening. Is it OK for you?

[glefloch]

Yes I'm on it, I should be able to create the pull request tonight

[aloubyansky]

@gsmet, @glefloch is on vacation for two more weeks.

[glefloch]

@aloubyansky, I thought adding the testFixtures class directory into the model would be enough. It fixes the issue related to the file not found but not the class loader conflict issue. I try updating the reproducer to avoid the lambda implementation but nothing changed. Could you have a look? I don't think this is related to the introduction of the model.

[aloubyansky]

I will.

[aloubyansky]

Just fyi, here is a dirty way of fixing the classloading issue

diff --git a/test-framework/junit5/src/main/java/io/quarkus/test/junit/QuarkusTestExtension.java b/test-framework/junit5/src/main/java/io/quarkus/test/junit/QuarkusTestExtension.java
index 36591a668..bb1102646 100644
--- a/test-framework/junit5/src/main/java/io/quarkus/test/junit/QuarkusTestExtension.java
+++ b/test-framework/junit5/src/main/java/io/quarkus/test/junit/QuarkusTestExtension.java
@@ -8,6 +8,7 @@ import java.io.IOException;
 import java.lang.reflect.Constructor;
 import java.lang.reflect.InvocationTargetException;
 import java.lang.reflect.Method;
+import java.nio.file.Files;
 import java.nio.file.Path;
 import java.nio.file.Paths;
 import java.util.AbstractMap;
@@ -117,6 +118,7 @@ public class QuarkusTestExtension
 
             Class<?> requiredTestClass = context.getRequiredTestClass();
             testClassLocation = getTestClassesLocation(requiredTestClass);
             final Path appClassLocation = getAppClassLocationForTestLocation(testClassLocation.toString());
 
             PathsCollection.Builder rootBuilder = PathsCollection.builder();
@@ -130,6 +132,9 @@ public class QuarkusTestExtension
                     rootBuilder.add(testResourcesLocation);
                 }
             }
+            if (Files.exists(testClassLocation.getParent().resolve("testFixtures"))) {
+                rootBuilder.add(testClassLocation.getParent().resolve("testFixtures"));
+            }

[aloubyansky]

The classes from testFixtures are going to be on the original test classpath and loadable from Quarkus tests by delegating to the system classloader. But in this case, a class from testFixtures is also referencing an application class, which we load in the Quarkus class loader. Which results in the LinkageError. So the diff above adds testFixtures to the Quarkus classloader.

[aloubyansky]

There are other (primarily Gradle-related) issues about recognizing and/or adding more test paths there. This is not the way we want to evolve. We need to properly integrate build system-specific (maven/gradle) workspace paths in here instead adding hacks.

[aloubyansky]

For 1.7.0.Final I guess we can live with this kind of quick fix, given that it's too late to introduce major changes.