Gradle Version: 3.0
Operating System and JVM version: Windows 10 64 Bit, 1.8.0_60 64 bit
AFAIK, Gradle guarantees that the compilation classpath will have a consistent (while arbitrary in regards to transitive dependencies) order.
It seems that starting with Gradle version 3.0, the order of the classpath entries of an Android project isn’t consistent anymore. This is a problem when using the Kotlin plugin because it breaks incremental compilation. I summarized the problem in https://code.google.com/p/android/issues/detail?id=221007.
Basicly, depending on whether you launch the build from Android Studio or from JRebel for Android, the compilation classpath will have two entries swapped.
When I reverted to Gradle 2.14.1, the problem seemingly disappeared.
thank you for reporting this. Could you provide some example project to reproduce this? Do you think that the order of the classpath entries change between Gradle runs - i.e. can we reproduce the problem without using Android Studio or JRebel?
When you configure the project, it writes the classpath to build/classpath/<timestamp>.txt
I noticed something new. It seems the classpath is different based on whether the daemon was running or not. When you kill the daemon and then call gradlew help, you get classpath A. On all subsequent runs, you’ll get classpath B. Until you kill the daemon and try again.
@Kirill_Rakhman: could you try this again with the freshly released Android Gradle plugin 2.2.2? My tests show that the classpaths are now produced in a stable order.