Gradle 5.0-rc-2 is now available for testing

News Build Tool
1

Gradle 5.0-rc-2 is now available for testing. See the 5.0-rc-2 release notes for more information and upgrade instructions.

3

I can see that support for “-u” (also, the longer version) was dropped. How am I supposed to load the “buildSrc” project via the Tooling API in 5.0? I used to provide “-u” but now the Tooling API fails because it does not find buildSrc as part of the project (which is of course true). Also, is there an alternative for when I know that a project does not have a settings.gradle. I mostly saw projects like this in tests.

4

Also, Gradle 5.0-rc-2 seems to be unable to download dependencies from http://bits.netbeans.org/nexus/content/groups/netbeans. It throws an exception like this (it works with older Gradle versions):

    > Could not resolve org.netbeans.api:org-netbeans-api-debugger:RELEASE81.
    > Could not get resource 'http://bits.netbeans.org/nexus/content/groups/netbeans/org/netbeans/api/org-netbeans-api-debugger/RELEASE81/org-netbeans-api-debugger-RELEASE81.pom'.
        > Could not HEAD 'http://bits.netbeans.org/nexus/content/groups/netbeans/org/netbeans/api/org-netbeans-api-debugger/RELEASE81/org-netbeans-api-debugger-RELEASE81.pom'.
            > Connection reset

EDIT: Actually, the last time it worked for Gradle 4.1. I’ll open an issue for both on GitHub.
EDI2: Apperantly, I’m very forgetful as I have alread reported this issue: https://github.com/gradle/gradle/issues/4297

6

Some feedback regarding rc-2:

  • the issue I reported against rc-1 is fixed as stated.
  • rc-2 bundles with Groovy 2.5.3 but the just released 2.5.4 has fixed an issue that may be relevant to Gradle regarding the memory consumption of the daemon. It may make sense to do another round of rc with Groovy 2.5.4, just fyi. GROOVY-8858
  • I had one issue where the gradle.plugin.edu.sc.seis:macAppBundle:2.2.3 plugin failed with > No value has been specified for property 'MacAppBundlePlugin jreHome'. on non-mac machines but worked with Gradle 4.10.2. That property isn’t actually necessary in my case so I was able to fix the build by simply setting the property to an arbitrary value.

I’m stumbling over a rather strange issue in one of my projects, though. With Java 11 my build fails with the following error message:

* Where:
Build file '/Users/jhuxhorn/Projects/huxi/lilith/build.gradle' line: 417

* What went wrong:
A problem occurred evaluating root project 'lilith'.
> Could not get unknown property 'gitHeadHash' for project ':lilith' of type org.gradle.api.Project.

That unknown property is created by my own (rather old) GitStatePlugin and I currently have no idea what could cause it to work on Java 8 but fail on Java 11. I don’t know if this is a Gradle 5.0 issue, an issue in my plugin, a Java 11 issue or a mix of all that. It feels like a Gradle issue…

Any hints would be appreciated since this is currently my only remaining blocker preventing a Java 11 build of my project.

7

@huxi, your GitStatePlugin is swallowing an exception when setting the gitHeadHash extra property, could it be that it is thrown somehow on Java 11? that could explain that extra property not being set.

8

Thanks for the pointer! I looked into it and the fix appears to be irrelevant if one doesn’t use Groovy’s own compilation cache. Since we’re not using that, we’ll postpone upgrading to 2.5.4 to Gradle 5.1.

1 Like
9

@huxi, the jreHome task input in the MacAppBundle plugin isn’t declared as optional, thus is required. Gradle 5 got more strict about this, see " Tasks & properties" in https://docs.gradle.org/5.0-rc-2/userguide/upgrading_version_4.html#potential_breaking_changes

10

I’ll take a closer look at that issue. I just wanted to give you my rc-2 findings before going down that rabbit hole. Thanks for the hint.

11

I nailed the issue down and it is, in part, indeed a Gradle problem.

My (old) code assumed user.dir to refer to a directory inside of the project file hierarchy. This was a valid assumption since the Gradle daemon seems to set that system property accordingly. My plugin still worked with --no-daemon even on Java 11.

But setting user.dir does not have the desired effect on Java 11 anymore, as you already know. I suspect that there’s still some code in the daemon that is setting that property. Otherwise my plugin would have already failed on Java 8 with the release candidates I tried.

I’d suggest to hunt down that piece of code and get rid of it, simply to get a consistent behavior regardless of the Java version used. This would surely cause some breakage but that way it would hit while doing a major build system version upgrade, giving plugin authors earlier feedback.