Some classes that would in the tooling-api jar in previous versions are now in the launcher jar. Yet the launcher jar is not on the classpath when using the gradleApi() as a dependency. This is causing NoClassDefFoundError exceptions. E.g. if I add gradleApi() I can not access org.gradle.launcher.GradleMain. Admittedly I’m most interested in org.gradle.tooling.internal.impl.DefaultGradleProject which is used from the tooling API.
For background, it appears that some of the new module loading in 1.12 is missing some connections. ToolingRegistratonAction.execute is being called in my IDE, which results in a NoClassDefFoundError for DefaultGradleProject. It looks like ToolingRegistrationAction (from gradle-tooling.jar) uses the class GradleProjectBuilder class that is in gradle-ide.jar, but that class uses DefaultGradleProject from the gradle-launcher.jar, which is no longer in the classpath. I believe the DefaultGradleProject class was in the tooling-api jar before and now appears to be in the launcher jar, yet the launcher jar is not in my classpath in 1.12-rc-1. Hence the JVM can’t load ToolingRegistrationAction. Seems the new module loading logic isn’t matching actual dependencies. Radim, it looks like you were specifically trying to get around this in commit 876ebfe.