Gradle 2.8-rc-2 is now available for testing

News
,
1

The Gradle team is pleased to announce the availability of the second release candidate for Gradle 2.8.

This release candidate fixes some regressions reported in the first RC for 2.8. Most of them are related to the update of the groovy version and but also other fixes like problems with mixing top level model elements and custom component/binary/source set types in a plugin or refinements to the IDE project name deduplication enhancements.

For a full list of new features, small improvements and bugfixes please check the release notes

Downloads and wrapper usage instructions are available at http://gradle.org/release-candidate. Please try Gradle 2.8-rc-2 with your projects and report any problems.

2

Everything fine with the usual three projects. :laughing:

3

I am still experiencing the bnd issue reported in the rc-1 thread. I haven’t tried switching from the gradle-bundle-plugin to Gradle’s native yet.

Caused by: groovy.lang.MissingMethodException: No signature of method: aQute.bnd.osgi.Builder.setProperties() is applicable for argument types: (java.util.LinkedHashMap) values: [[Import-Package:sun.misc.*;resolution:=optional, Export-Package:com.github.benmanes.caffeine;com.github.benmanes.caffeine.base;com.github.benmanes.caffeine.cache;com.github.benmanes.caffeine.cache.stats;com.github.benmanes.caffeine.locks, ...]]
Possible solutions: setProperties(java.io.File), setProperties(java.util.Properties), getProperties(), getProperties(), setProperties(java.io.File, java.io.File), addProperties(java.io.File)
4

Hi Ben,

We have documented this behavior in the Groovy 2.4.4 upgrade section of the release notes: https://docs.gradle.org/release-candidate/release-notes#upgraded-to-groovy-2.4.4

The error you are seeing is related to the fact that Groovy now enforces the right type of setter, whereas previously the method that was called was undetermined: depending on the JVM or the order of declaration of methods, a different one could be called. In short: the plugin you are using requires a fix. If you can, it would indeed be a good idea to try the native bnd plugin from Gradle.

6

I think the problem is here

instructions should be a java.util.Properties instance but is a LinkedHashMap

7

I raised an issue with the plugin https://github.com/TomDmitriev/gradle-bundle-plugin/issues/34

8

@CedricChampeau, @Lance_Java, @sterling

Thanks a bunch! Sorry that I didn’t investigate the issue first. I switched to the native plugin and it works like a champ.

9

No worries @Benjamin_Manes, thanks for reporting the problem.

10

This is in no way scientific but the same exact project, one with gradle wrapper 2.8-rc-2 and with gradle binary 2.7:

It’s a fairly large multi-project java build with bunch of external plugins.

# ./gradlew --stop 
# ./gradlew --daemon clean build 
Total time: 4 mins 25.725 secs 
# ./gradlew clean build 
Total time: 3 mins 17.782 secs 

# gradle --stop 
# gradle --daemon clean build
Total time: 2 mins 48.436 secs
# gradle clean build
Total time: 2 mins 26.799 secs

Ran both twice just to make sure and took the lower number (2.8 ran four times – the first “build” took over 6.5 minutes for some reason but it did not repeat that since - so I’m assuming it was doing filesystem/cache setups or something)

11

Thanks @aram535. We definitely wouldn’t expect 2.8 to be significantly slower than 2.7 in that situation.

2.8 consumes more memory than 2.7, so if you have any custom JAVA_OPTS/GRADLE_OPTS, that might have some impact. Our performance tests haven’t shown any major changes in clean build times, but 2.8 should be faster than 2.7 for incremental builds. You can log-in as a guest to see the graph. Yellow is 2.7, red is 2.8 and blue is master/2.9.

What’s your environment like? OS and JDK and any important environment variables (JAVA_OPTS, GRADLE_OPTS, etc). Which plugins are you using?

I’m guessing you intended ./gradlew --daemon ... to mean that you were using the daemon for all invocations? If you only use --daemon once and don’t have the daemon turned on all the time, only the first build is using the daemon. From the numbers, it seems like you have the daemon turned on, but I just wanted to be clear.

Do you have org.gradle.parallel turned on?

Would you be willing to share a few --profile reports? (you can send them privately to me sterling at gradle.com).

12

Hi @sterling,

As I said this was not all scientific or indicitive of 2.8 being slower by itself. It maybe one of a dozen plugins or bad groovy code that is in this build. Everything from Findbugs, PMD, Sonarqube (not on the chain) to Jooq-code-generation, Jacoco and artifactory are enabled on this build. It was just interesting that it was bit slower.

No JAVA_OPTS or GRADLE_OPTS set.

I do have a gradle.properties in my home dir:

org.gradle.daemon=true
org.gradle.configureondemand=true
org.gradle.prallel=true
org.gradle.wokers.max=10

This was my dev machine which is a i7-4820K @ 3.7Ghz Windows 10 64bit w/32gb of memory.
JVM = Java 1.8.0_60 - 64bit

The --daemon was just to force invoke it the for the first run, The 2nd incremental was run without it to use any caching/pre-compilation that the daemon had done.

I will do this test again on our linux dev environment on Monday to see if it’s just Windows or not – and will be happy to share the --profile outputs in either case.