Gradle 2.8-rc-1 is now available for testing

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

This release delivers a number of performance improvements including faster incremental builds, faster source compilation when using continuous mode, and general performance improvements that apply to all builds. In particular, large builds with many source files should see dramatic improvements in incremental build speed.

We’ve also made improvements to the new Gradle TestKit to make it easier to inject plugins under test into test builds.

In addition to these features, Gradle continues to improve with a variety of small improvements and bug fixes. Please check the release notes for more information.

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

1 Like

This topic is now a banner. It will appear at the top of every page until it is dismissed by the user.

Everything fine with the usual three projects.

do you have a bot for that @huxi ?

My build fails due to an OSGi manifest problem, works in 2.7. I’m using org.dm.bundle which is about the same as Gradle’s but was faster to work with. Did the bnd version change and therefore I should switch to Gradle’s native plugin?

The project in question,

* What went wrong:
Could not copy MANIFEST.MF to '/Users/ben/projects/caffeine/tracing/api/build/tmp/jar/MANIFEST.MF'.
> No signature of method: aQute.bnd.osgi.Builder.setProperties() is applicable for argument types: (java.util.LinkedHashMap) values: [[Export-Package:com.github.benmanes.caffeine.cache.tracing.*, ...]]
  Possible solutions: setProperties(java.io.File), setProperties(java.util.Properties), getProperties(), getProperties(), setProperties(java.io.File, java.io.File), addProperties(java.io.File)

* Try:
Run with --info or --debug option to get more log output.

* Exception is:
org.gradle.api.GradleException: Could not copy MANIFEST.MF to '/Users/ben/projects/caffeine/tracing/api/build/tmp/jar/MANIFEST.MF'.
	at org.gradle.api.internal.file.AbstractFileTreeElement.copyTo(AbstractFileTreeElement.java:79)
	at org.gradle.api.internal.file.collections.MapFileTree$FileVisitDetailsImpl.getFile(MapFileTree.java:164)
        ....
Caused by: groovy.lang.MissingMethodException: No signature of method: aQute.bnd.osgi.Builder.setProperties() is applicable for argument types: (java.util.LinkedHashMap) values: [[Export-Package:com.github.benmanes.caffeine.cache.tracing.*, ...]]
Possible solutions: setProperties(java.io.File), setProperties(java.util.Properties), getProperties(), getProperties(), setProperties(java.io.File, java.io.File), addProperties(java.io.File)
	at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:58)
	at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:486)
	at org.dm.gradle.plugins.bundle.JarBuilder.withProperties(JarBuilder.groovy:81)
	...

Nope, just coincidence. But I should have one. :smiley:
Or you could provide a special alert mailing list just for RC announcements…

Thanks @Benjamin_Manes, I’ve reproduced here.

We’ll let you know when we have something to test. If the built-in OSGi plugin was using something newer (e.g. bndlib 2.4.0+), would it work for you?

Honestly I don’t care too much. I don’t use OSGi but added it for users and grabbed the first plugin I found. If I have to switch to Gradle’s native plugin to use the update and fix the build then it shouldn’t be too much trouble.

As an aside, I don’t know how Gradle does its caching but it might be advantageous to integrate this policy. It provides a near optimal hit rate with very simple, low overhead code.

Thanks! @lhotari’s been looking at how to optimize our caches (we’re using Guava for some right now), so he’ll be interested to check that out.

I was only asking about the OSGi version because someone else asked today if/when we were going to update.

I wrote a large chunk of Guava’s cache, but was unable to get a simple performance fix after leaving (up to 25x faster). That cache uses LRU based on my ConcurrentLinkedHashMap, but the Guava’s focus was on features first and the performance iteration never occurred. So hit rates are average, but throughput is below my original intent. But while my current project is JDK8 (therefore unusable by Gradle), the eviction policy could be useful for disk caching or other custom areas.

I’m having a compatibility issue. In Gradle 2.7, the following works fine:

configurations { provided }
sourceSets.main.compileClasspath += [configurations.provided]

In 2.8-rc-1, I get

Cannot cast object '[configuration ':provided']' with class 'java.util.ArrayList' to class 'org.gradle.api.file.FileCollection' due to: groovy.lang.GroovyRuntimeException: Could not find matching constructor for: org.gradle.api.file.FileCollection(org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated)

Removing the brackets and adding just the single configuration makes it work, but an earlier Gradle version required the brackets.

@jochenberger, You might want to try the gradle-extra-configurations-plugin for provided scopes. Since my build got past the dependency step, likely however they add the configuration doesn’t run into this incompatibility issue.

Thanks @jochenberger, we’re going to look at the regressions and spin another RC (probably early next week). We think this is related to the Groovy update.

I noticed this as well with some of our projects, though strictly speaking it seems like using [configuration] isn’t quite correct to begin with, as the API for FileCollection.plus() takes other FileCollections, not [FileCollection].

21 posts were split to a new topic: 2.8-rc-1 regression related to Grgit plugin

I think I remember being forced to use an array instead of a single Configuration by an earlier Gradle version.

This topic is no longer a banner. It will no longer appear at the top of every page.