This message was deleted.
# caching
s
This message was deleted.
m
I'm not sure this is already present in gradle 5, but you could have a look at reproducibleFileOrder (and possibly also preserveFileTimestamps) in the Jar task.
v
That wouldn't help @Markus Maier. As far as I understood it is not about the order within the files. Especially because normalization type is "Runtime classpath", which already mitigates differences of file order within the Jars. But for a classpath, the order of the jars on the classpath is significant, especially if some FQCN is present in multiple jars as then the first one found on the classpath is used. So you have to find out why the classpath order is different on that task for different runs.
👍 1
r
thanks for input, i'll dig a bit further and maybe write a custom task to print classpath ordering to try ID issue
v
The build scan hopefully shows the ordering already. I think you just need to put left and right side in a diff tool and should see the difference, or have the difference highlighted in the build scan. If not, I'd say that qualifies for a bug report or feature request to Develocity.
r
Ah hu, The culprit is the following for the diff in ordering
org.openjfx:javafx-swing:11.0.2 (javafx-swing-11.0.2-linux.jar)
which is added to the build not directly but via a plugin as far as i can tell with the following code
Copy code
plugins {
    id 'org.openjfx.javafxplugin' version '0.0.7' apply false
}

if (JavaVersion.current().isJava9Compatible()) {
    apply plugin: 'org.openjfx.javafxplugin'
    javafx {
        version = "11.0.2"
        modules = ['javafx.controls',
                   'javafx.fxml',
                   'javafx.swing'
        ]
    }
}
v
Oh, yeah that JavaFX Plugin version is actually pretty misbehaving. Better update to 0.1.0 or newer if exists, where there were significant improvements. That might also solve your issue eventually.
r
Thanks will give it a go!
👌 1