Dear Community, Good morning! I have a little Gr...
# community-support
j
Dear Community, Good morning! I have a little Gradle retrocomputing challenge for you today. Let's start with assuming that I would like to build the native-platform libraries with a very outdated Gradle 4.4.1 because Reasons, and that I've already done most of the work breaking slaughtering “downgrading” the buildscript. This version of the
native-platform
project has three subprojects:
native-platforms
again,
file-events
and `test-app`:
Copy code
Root project 'native-platform'
+--- Project ':file-events'
+--- Project ':native-platform'
\--- Project ':test-app'
In
native-platform
there is a test fixture interface that is needed by the tests in `file-events`:
Copy code
native-platform
└── src
    └── testFixtures
        └── java
            └── net
                └── rubygrapefruit
                    └── platform
                        └── testfixture
                            └── JniChecksEnabled.java
In
file-events
, somewhere under
src/test/groovy
there is a Groovy class that references the test fixture interface above. Now the question for you is, how do I get the tests of both
native-platform
and
file-events
to compile and run and find the Java test fixture interface without any of those: •
testImplementation testFixtures(...)
here • the
java-test-fixtures
plugin here • all the current fancy APIs that didn't exist back in the time of Gradle 4.4.1: there is what is only allowed (and a big thanks to the project for keeping all the old docs and repos online). Out of frustration I copied
native-platform/src/testFixtures/java
to
native-platform/src/test/java
and
file-events/src/test/java
and now the tests work for me, but maybe you know better?
(and since then I discovered that the
file-events
lib has been split to its own project, which makes this problem now completely irrelevant for any practical purpose, but I still want to know)
e
Gradle often uses new Gradle features, so if you're trying to bootstrap your way up to the current version, I think it would work better one version at a time
j
Well that was considered but with so many versions back it's not quite practical so I have other plans. But we might have to do something like that for Kotlin as we lack alternatives for that one 😞