This has potential to affect current clients that use the daemon. Can we prioritize for 1.4.

Until it is fixed perhaps one of the following workarounds might be useful:

• The project that is built with a custom distro can use org.gradle.daemon.registry.base property. For example, it can be specified in gradle.properties file inside the project dir. The value of the property is the dir where the daemon registry file (addresses of active daemons) and daemon log files. If this directory is customized only the daemons from this custom dir / registry file will be used. Using this property one can configure single daemon registry dir in all projects that use a custom distribution. Beware that is property is internal at the moment.
• Similar as above. One can use org.gradle.jvmargs and configure slightly unconventional jvm opts. For example: -Xmx1033M. The gradle daemons at the moment are matched for compatibility using the exact jvm opts. So only daemons with given jvm opt will be compatible. This workaround uses a public property but it relies on daemon compatibility matching criteria that might change in future (although not soon, certainly not sooner than a proper bugfix for this issue).

Unfortunately neither of those approaches works for us. One of our requirements is that the same custom distro is used across all projects - we've taken away the ability for a project to be able to customize the distro - that way we can control the system that is being used company-wide across all projects.

Ok, I understand.

If every single project uses the custom distro then there should not be a problem with daemon compatibility?

The issue happens when we release a new version of the custom distro which is based upon the same core gradle distro. Our custom distro can recognize this and then download/install the new distro. When I tried to use the tooling api to then launch the new distro from the new location, what actually launched was the same distro that was originally running - because the core gradle version, java version, & jvm args were the exact same it re-used the same daemon.

Thanks for clarification!

So I see this was fixed/added with gradle 1.4. How do I use it? Or should gradle automatically figure out that a new daemon is needed based on the use cases I provided?

It's transparent.

The way it works is that it may actually use existing daemon processes (if it matches based on JVM args, Gradle version etc.), but will use the init scripts from your custom distribution just like it was actually running from that.

What about other things other than the init scripts? Part of the custom distribution are custom jar files. If a previous version's jars are already on the daemon's classpath and then a new custom distribution (based on the same core gradle distro) which has updated versions of these classes, will those new versions of the classes be picked up or will the daemon continue to use the old version of the classes that are already in the classloader?

Gradle won't load arbitrary jars from a distribution. The only thing that is supported is adding init scripts.

Say for example that you want to inject some custom jars into the build script classpath via init scripts though. This can still work, because you reference the location of your jars relative to the location of your init script. You can get the files via the Script API: http://www.gradle.org/docs/current/dsl/org.gradle.api.Script.html

Ok i see in my own init scripts where i am wiring my packaged jar files in. I just need to make sure that whatever classes/jars the previous init loaded that when the new custom distro (same core gradle version) loads its init script and loads its jars (which will contain the same class names) that the newly-loaded ones are the ones which take precendence.

Anything you load in an init script will not persist across builds (unless you are doing something unsupported such as messing directly with classloaders), therefore you don't need to worry about pollution/precedence.

Perfect! Thats what I was looking for. Thanks so much!