[GRADLE-2408] Daemons do not consider what distribution they are running from, potentially ignore distribution init scripts Created: 30/Jul/12  Updated: 28/Jan/13  Resolved: 07/Jan/13

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 1.4-rc-1

Type: Bug
Reporter: Luke Daley Assignee: Luke Daley
Resolution: Fixed Votes: 0


Consider a user with a standard Gradle 1.0, and a customised Gradle 1.0 distribution with custom init scripts.

The user may have a daemon running from the standard distribution. When they go and try to run a build that uses their custom distro via the wrapper the original daemon is incorrectly considered compatible.

The solution may be to include the daemon classpath in the compatibility check or something to that effect.

Comment by Peter Walker (Inactive) [ 18/Oct/12 ]

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

Comment by Szczepan Faber [ 19/Oct/12 ]

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).
Comment by Eric Deandrea [ 19/Oct/12 ]

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.

Comment by Szczepan Faber [ 19/Oct/12 ]

Ok, I understand.

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

Comment by Eric Deandrea [ 19/Oct/12 ]

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.

Comment by Szczepan Faber [ 19/Oct/12 ]

Thanks for clarification!

Comment by Eric Deandrea [ 28/Jan/13 ]

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?

Comment by Luke Daley [ 28/Jan/13 ]

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.

Comment by Eric Deandrea [ 28/Jan/13 ]

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?

Comment by Luke Daley [ 28/Jan/13 ]

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

Comment by Eric Deandrea [ 28/Jan/13 ]

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.

Comment by Luke Daley [ 28/Jan/13 ]

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.

Comment by Eric Deandrea [ 28/Jan/13 ]

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

Generated at Wed Jun 30 12:21:06 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.