Gradle 2.3-rc-1 is now available for testing

Old Forum Archive
1

The Gradle team is pleased to announce that the release candidate for Gradle 2.3 is now available.

Download links and release notes can be found as always at http://gradle.org/release-candidate.

Please try Gradle 2.3-rc-1 with your projects and let us know your experiences.

Cheers,

Daz

2

Everything fine in my usual three projects.

3

Oops, I answered too soon. Build server found a problem. Will report it in a separate topic.

4

Hi, I still have no news about the proposed fix (https://github.com/adammurdoch/native-platform/pull/7) for a regression that occurred in 1.12 (https://issues.gradle.org/browse/GRADLE-3158). I know that this doesn’t seem to affect a lot of people, but it would be nice to have some kind of update. Again, if I may help in any way please tell me.

Edit: as a side note, tested 2.3-rc1 in 5 projects (one with 58 subprojects) and everythings looks fine.

5

It looks like a change was made to the ‘build’ task in 2.3 that prevents it from being visible until being explicitly referenced.

Minimal example: https://github.com/stormbeta/gradle-2.3-issue

Running ./gradlew should cause the build task to be called, but it isn’t. If I downgrade the wrapper to 2.2.1, this works as expected.

If any explicit reference to the build task is obtained, even just ‘tasks.build’, it will start working again.

6

Hi Jason,

We changed the build task to be deferred in this release for practical reasons.

What’s the case where this actually causes a problem? You might want to use ‘tasks.findByName’ instead of ‘matching’.

7

Luke,

I had a utility method for deferring configuration involving tasks that my plugin wasn’t strictly responsible for creating (either directly or via applied plugins) and that technically might not be created at all (similar to ‘tasks.withType’).

It was confusing at first because the ‘tasks’ task would indicate tasks were wired up correctly, but actually running the build would fail since the ‘build’ task was never created.

In hindsight, tasks like ‘build’ would necessarily be present on any real project the plugin would be used with, so it’s safe to use something like ‘findByName’ instead.

Thanks for the clarification!

8

Note that findByName() will return null if the build task isn’t there, but if it is there but not created yet (as is the case now with 2.3) it will be created and you’ll have access to it. Therefore, if you check for a null return value and act accordingly everything should still work as before.

9

Still doesn’t run on OpenShift.

10

Right - the original use case was intended for optional plugins that created a task after being applied and that neglected to use a distinct type for the task (so ‘plugins.withId’ and ‘tasks.withType’ wouldn’t be enough). Admittedly this is an edge case and well-designed plugins should be using distinct types for their tasks.

‘findByName’ will work for the build task as long as I ensure a plugin that provides the build task has been applied first (which I’m already doing). Otherwise it could return null even if a plugin applied after mine would have provided it, and I don’t want to depend on plugin application order.