Uploaded image for project: 'Gradle'
  1. Gradle
  2. GRADLE-1073

Gradle daemon should gracefully handle version changes



    • Type: Improvement
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: 0.9.1
    • Fix Version/s: 0.9-rc-3


      Repro steps:

      1. stop any running gradle daemon
      2. install 0.9-20100726131918+0200 via the gradle wrapper
      3. gradle clean
      4. notice the gradle daemon start
      5. leave the daemon running
      6. install 0.9-20100728180850+0200 via the gradle wrapper
      7. gradle clean
      8. notice the following serialization issues
        java.io.InvalidClassException: org.gradle.launcher.GradleDaemon$BuildArgs; local class incompatible: 
        stream classdesc serialVersionUID = -9202617733128175087, local class serialVersionUID = 4032985459256264336
                at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:562)
                at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
                at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
                at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
                at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
                at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
                at org.gradle.launcher.GradleDaemon.run(GradleDaemon.java:46)
                at org.gradle.launcher.GradleDaemon.main(GradleDaemon.java:29)

      It appears that the gradle process does a blind check for a running daemon and if it's up, attempts to communicate with it. Better would be issuing a version check first, shutting down and restarting the daemon if versions are incompatible.

      A minor issue perhaps, but goal number one with the daemon is to make it invisible.

      Another use case for this would be not an upgrade of gradle, but simply moving between different gradle-built projects that are using different versions in the wrapper. In this case, it might be best to start a second daemon on its own dedicated port. It's a bit of an edge case, but if a user is toggling between two projects and issuing builds, they'll continually incur the daemon startup overhead. Shouldn't be a problem to just spin up a new daemon, but this does create the possibility of stale daemons lying around after a legitimate upgrade occurs.




            adammurdoch Adam Murdoch
            cbeams Chris Beams
            0 Vote for this issue
            0 Start watching this issue