Gradle 3.1 and customized Gradle distro

Help/Discuss
1

My company uses a custom Gradle distro which ships a custom init script packaged as a jar file inside the distro’s lib directory (DISTRO/lib/acme-extensions.jar). We currently use Gradle 2.14.1 and it works well.

I want to migrate this custom distro to Gradle 3.1 and I now have issues which seem to relate to the daemon being enabled by default since 3.0.

This is the scenario that I’ve identified:

  • I run a first build with Gradle vanilla 3.1, this build starts the daemon and logs the message “Starting a Gradle Daemon (subsequent builds will be faster)”
  • I try to run another build which depends on our custom Gradle distro based on 3.1. However since there’s already a Gradle daemon running, Gradle reuses the existing daemon whose classpath doesn’t contain the jar with my custom init script. The build fails with the error “Could not get unknown property ‘com’ for build of type org.gradle.invocation.DefaultGradle.”
  • Killing the running Gradle daemon and running the second build works this time

It seems that the logic for reusing an existing daemon only considers the version of Gradle being used (3.1 here).

Can you confirm if using a custom Gradle distro is compatible with the use of the daemon. It looks to me that this use case isn’t supported.

2

Init scripts need to be placed into the init.d directory of your distribution, they cannot be packaged in a jar. Any additional jars need to be added to the initscript classpath by using a relative path (from the init.d dir to the jar in the lib dir).

I’m actually surprised it worked before, that’s an oversight on our side. Gradle is not intended to pick up unknown jars in the lib dir.

3

I should have been more precise in describing how this custom Gradle disto works. I have a jar file which contains my custom classes and I also have an init.d directory and an init script which applies an init script plugin from the jar file.

You’re right that just having a jar file won’t work.

4

Okay, thanks for clarifying, that should indeed work. Could you share that init script?

5

I think you need to stop the daemon (gradle --stop) before you attempt to install a new version. I think the issue has become a problem with version 3 is not because there’s an issue with this version but just because it’s always running which was likely not the case for earlier versions.

6

This is not the case.

7

Sorry for the late reply. The init script is really simple, it’s just a bootstrap to apply an Init Script plugin packaged inside a custom jar file inside the Gradle distro.

initscript {
  dependencies {
    classpath files("${gradle.gradleHomeDir}/lib/gradle-extensions.jar")

    logger.lifecycle "Added library 'GRADLE_HOME/lib/gradle-extensions.jar' to the init script's classpath"
  }
}

apply plugin: com.acme.gradle.artifactory.ArtifactoryInitPlugin

I agree with @Don_Henry that the problem is caused by Gradle 3.x enabling the daemon by default. This problem already existed in 2.x (when explicitly starting the daemon) but it’s worse now since the daemon is started all the time.

Because I’m using a customized version of Gradle 3.x (e.g. with a custom jar gradle-extensions), there is always a risk that the daemon which is running my build doesn’t have this custom jar on the classpath (because it was started from a vanilla Gradle distro).

8

This is the problem. You need to specify the path relative to the init script ("${initscript.sourceFile.parentFile}/lib/gradle-extensions.jar"), not relative to the Gradle home. The Gradle home can be the home of any compatible daemon.

9

Oh, I see. I’ll test that tomorrow !

Thanks very much Stefan.

10

I tested and it worked like a charm.

I just had to change the path to ${initscript.sourceFile.parentFile.parentFile}/lib/gradle-extensions.jar.

Thanks Stefan !