Gradle 2.4-rc-1 fails to retrieve GradleProject model

Bugs
,
1

I’m adding my custom build model to be queried and if I also query the GradleProject (or IdeaProject or EclipseProject) model, the build fails.

The exception I get is the following: https://gist.github.com/kelemen/209eafe38ac8820c654d.

To reproduce this bug, run “gradlew :netbeans-gradle-default-models:test --tests org.netbeans.gradle.model.java.MultiLevelJavaProjectTest.testBuiltInModels” for my project (the link points to a commit where the issue can be reproduced)

This works when using Gradle 2.2 (2.3 has a know bug, so it does not work at all).

2

It seems that the cause is that I call project.getTasks().getNames() before retrieving the models. If I don’t call this method, the models can be retrieved fine. This should mean, that any project calling this method will fail to be loaded through the Tooling API.

3

Further investigation shows, that its not the getNames method which matters but calling project.getTasks().findByName("dependencyInsight"). Of course, the best way to reproduce the issue is calling:

for (String name: project.getTasks().getNames()) {
    tasks.findByName(name);
}

However, I checked and the only problem is calling findByName with "dependencyInsight" (anything else returned by getNames() is not a problem).

4

Thanks for the report, looking into it.

5

I’ve fixed this. Will post the snapshot build number when it goes out if you want to verify pre rc2.

BTW, if you want to include a 2.4-rc-1 specific patch you need to cast the task container to TaskContainerInternal and call discoverTasks() before calling tasks.findByName("dependencyInsight"). To be clear, this won’t be required for rc2, or final.

6

Thank you. What does discoverTasks do (other than working around this issue)? That is, what more tasks can I expect to find with it?

7

Tasks added exclusively through rules.

The built in tooling models all do this. At the moment, they offer the only public API for getting all of the executable tasks. This is not a new phenomenon, as even with the old (i.e. not rules based) model just querying the task container at configuration time via the public API didn’t give you everything you could execute.

It’s unclear what public API we’ll offer here at this point beyond the existing public tooling models that do the right thing.

8

I can verify that the issue has been fixed. Thank you.