Can't call evaluate() on Project instances returned from ProjectBuilder with gradle-1.12-rc-1

Old Forum
1

Example project that demonstrates the issue

Calling evaluate() on Project instances built using ProjectBuilder causes a NoClassDefFound exception inside Gradle:

‘’’ java.lang.NoClassDefFoundError: org/gradle/tooling/internal/impl/DefaultGradleProject

at org.gradle.plugins.ide.internal.tooling.ToolingRegistrationAction.execute(ToolingRegistrationAction.java:29)

at org.gradle.plugins.ide.internal.tooling.ToolingRegistrationAction.execute(ToolingRegistrationAction.java:24)

at org.gradle.configuration.project.PluginsProjectConfigureActions.execute(PluginsProjectConfigureActions.java:31)

at org.gradle.configuration.project.PluginsProjectConfigureActions.execute(PluginsProjectConfigureActions.java:22)

at org.gradle.configuration.project.ConfigureActionsProjectEvaluator.evaluate(ConfigureActionsProjectEvaluator.java:34)

at org.gradle.configuration.project.LifecycleProjectEvaluator.evaluate(LifecycleProjectEvaluator.java:55)

at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:493)

at org.gradle.api.internal.project.AbstractProject.evaluate(AbstractProject.java:80)

at BreakingTest.can evaluate ProjectBuilder(BreakingTest.groovy:15) Caused by: java.lang.ClassNotFoundException: org.gradle.tooling.internal.impl.DefaultGradleProject

at java.net.URLClassLoader$1.run(URLClassLoader.java:202)

at java.net.URLClassLoader.findClass(URLClassLoader.java:190)

at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)

at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

… 9 more ‘’’

If I switch back to gradle-1.11 there’s no issue.

2

This is indeed a bug that we should fix prior to the release. Thanks for excellent report!

3

Just so you know, the 'evaluate() 'method is internal (it’s not declared on ‘Project’, it just happens to be on the internal implementation). This means it may change, move or break at any time. You generally should avoid using internal methods.

4

Fair enough. Is there another method for testing things that require the project to be in an evaluated state? We could use the Tooling API, but that doesn’t allow us to inspect the project state and seems overkill for unit testing purposes.

5

Perhaps something could be put into 2.0 to disallow calling internal methods not exposed by the gradle interfaces. Delegating proxies spring to mind…

6

Please don’t. Use cases come up that the Gradle developers can’t anticipate, which are possible if we can call internal methods. The project is open source, we can see the method we need and can adapt when they change. If methods become un-callable, we’ll be forced to fork Gradle just to make method available. I think it’s understood that calling internal methods isn’t supported.

7

@jason, You shouldn’t need to use evaluate() to configure the project, you can just drive it from your test as you would from a build script.

8

@justin, I was thinking that preventing usage of the private API would force the public API (interfaces) to improve more rapidly.

9

Is there a way to force an evaluation via the public api? I have one part of our large build which simply doesn’t work if I have configure-on-demand=true. I’d like to be able to force evaluation of all sub-projects if this one task gets executed. So, basically, I’d like to turn configure-on-demand on/off dynamically.

2 Likes