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

Gradle daemon should gracefully handle version changes

    XMLWordPrintable

    Details

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

      Description

      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.

        Attachments

          Activity

            People

            Assignee:
            adammurdoch Adam Murdoch
            Reporter:
            cbeams Chris Beams
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: