Gradle Support

[narkaTee]

Are you interested in contributions to make retest compatible with gradle projects?
I have a working version locally with only minor modifications and would be happy to help.

[beatngu13]

Hey @narkaTee, thanks for opening this issues. Well, Gradle support sounds great and we are always happy to receive pull requests. But what exactly are the issues you are facing with Gradle and what are the adaptions you made so far?

[narkaTee]

There are only two minor issues:

1. gradle upgrades a transitive dependency (kryo) which breaks result file persistence
2. The Default MavenConformFileNamerStrategy does not work with gradle because the paths are different

The first is fixable in the build.gradle with a constraint and will probably vanish if dependencies get more stable (I'm guessing here 😉)

To solve the second one, I modified RecheckWebImpl to allow passing a FileNamerStrategy implementation in the constructor and wrote a GradleConformFileNamerStrategy which uses a different path.
In the test setup I pass a Instance of the Gradle file namer.

That's not a nice solution, just a quick hack to check if there are other problems.
A permanent solution could be some sort of configuration maybe in the retest.properties or a RetestWebBuilder which injects the correct FilerNameStrategy.
Any other ideas?

[beatngu13]

1. gradle upgrades a transitive dependency (kryo) which breaks result file persistence

Hmmm, how comes Gradle updates this? We use the most recent, stable version (4.0.2), everything beyond (5+) are "just" release candidates. Any idea how to fix this?

2. The Default MavenConformFileNamerStrategy does not work with gradle because the paths are different

I assume you use something like src/integTest? Right now we are updating recheck (see retest/recheck#123) and recheck-web (see #171) such that you can pass RecheckOptions to both RecheckImpl and RecheckWebImpl like this:

RecheckOptions opts = RecheckOptions.builder()
        .fileNamerStrategy( new MyCustomFileNamerStrategy() )
        .build();
Recheck re = new RecheckImpl( opts );

However, your GradleConformFileNamerStrategy is something we would really appreciate, so feel free to create a corresponding PR in recheck. And please let us know if we can help.

[narkaTee]

This are the dependency infos from gradle:

testRuntimeClasspath - Runtime classpath of source set 'test'.
+--- junit:junit:4.12
|    \--- org.hamcrest:hamcrest-core:1.3
\--- de.retest:recheck-web:0.8.0-SNAPSHOT
     +--- de.retest:recheck:0.14.0
[...snip...]
     |    +--- com.esotericsoftware:kryo:4.0.2 -> 5.0.0-RC1
     |    |    +--- com.esotericsoftware:reflectasm:1.11.7
     |    |    +--- org.objenesis:objenesis:2.6
     |    |    \--- com.esotericsoftware:minlog:1.3.0
     |    +--- de.javakaffee:kryo-serializers:0.45
     |    |    \--- com.esotericsoftware:kryo:5.0.0-RC1 (*)
[...snip...]

It tells us de.javakaffee:kryo-serializers:0.45 has a dependency on com.esotericsoftware:kryo:5.0.0-RC1.
Gradle then upgrades the dependency which de.retest:recheck:0.14.0has to com.esotericsoftware:kryo:4.0.2 to the never version to statisfy the dependency of de.javakaffee:kryo-serializers.

Maven handles such conflicts by downgrading the dependency.

There are two ways to fix this:

1. On the user side by adding a gradle constraint:

dependencies {
    testImplementation 'junit:junit:4.12'
    testImplementation 'de.retest:recheck-web:0.8.0-SNAPSHOT'
    constraints {
        testImplementation('com.esotericsoftware:kryo:4.0.2') {
            force = true
        }
    }
}

2. On the restest side: using kryo-serializers 0.43 could fix this problem because it does not depend on kryo 5.0.0-RC1. I testet this very quickly and it solves the dependency problem.

The RecheckOptions look good!
I opened a PR for the gradle file namer (retest/recheck#124), details are in there.

[beatngu13]

We just released v0.8.0 which allows you to use RecheckOptions.

We are planning to downgrade kryo-serializers and integrate your GradleConformFileNamerStrategy with the next release. Thank you so far!

[beatngu13]

Resolved via retest/recheck#124, comes with the next recheck/recheck-web release.