[GRADLE-1619] Provide infrastructure for plugin/task developers to execute gradle builds in a controlled manner for integration testing Created: 16/Jun/11  Updated: 04/Aug/15  Resolved: 04/Aug/15

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 2.6-rc-1

Type: Bug
Reporter: Luke Daley Assignee: Luke Daley
Resolution: Fixed Votes: 13

Issue Links:
Related
Related to GRADLE-819 Allow plugins to use Gradle's integra... Resolved

 Description   

GradleLauncher has runtime dependencies that it's not convenient for plugin developers to declare.

Notably, the jna-posix-1.0.3.jar is not added when you depend on gradleApi().

org.gradle.util.UncheckedException: java.lang.NoClassDefFoundError: org/jruby/ext/posix/POSIXHandler
	at org.gradle.util.UncheckedException.asUncheckedException(UncheckedException.java:31)
	at org.gradle.api.internal.project.DefaultServiceRegistry.invoke(DefaultServiceRegistry.java:181)
	at org.gradle.api.internal.project.DefaultServiceRegistry.get(DefaultServiceRegistry.java:123)
	at org.gradle.logging.LoggingServiceRegistry.<init>(LoggingServiceRegistry.java:44)
	at org.gradle.logging.LoggingServiceRegistry.newCommandLineProcessLogging(LoggingServiceRegistry.java:51)
	at org.gradle.api.internal.project.GlobalServicesRegistry.<init>(GlobalServicesRegistry.java:44)
	at org.gradle.initialization.DefaultGradleLauncherFactory.<init>(DefaultGradleLauncherFactory.java:52)
	at org.gradle.GradleLauncher.getFactory(GradleLauncher.java:88)
	at org.gradle.GradleLauncher.createStartParameter(GradleLauncher.java:111)
	at org.gradle.GradleLauncher.newInstance(GradleLauncher.java:100)
	at org.gradle.plugins.textmate.ProjectSpec.command(ProjectSpec.groovy:51)
	at org.gradle.plugins.textmate.ProjectSpec.run(ProjectSpec.groovy:56)
	at org.gradle.plugins.textmate.StructureGenerationSpec.generation for no subprojects(StructureGenerationSpec.groovy:25)
Caused by: java.lang.NoClassDefFoundError: org/jruby/ext/posix/POSIXHandler
	at org.gradle.logging.internal.TerminalDetector.isSatisfiedBy(TerminalDetector.java:73)
	at org.gradle.logging.internal.TerminalDetector.isSatisfiedBy(TerminalDetector.java:29)
	at org.gradle.logging.internal.OutputEventRenderer.addStandardOutputAndError(OutputEventRenderer.java:54)
	at org.gradle.logging.LoggingServiceRegistry.createOutputEventRenderer(LoggingServiceRegistry.java:115)
	at org.gradle.api.internal.project.DefaultServiceRegistry.invoke(DefaultServiceRegistry.java:179)
	... 11 more
Caused by: java.lang.ClassNotFoundException: org.jruby.ext.posix.POSIXHandler
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
	... 16 more

The thing to do may be to expose another utility method such as gradleTesting()

 Comments   
Comment by Luke Daley [ 20/Jun/11 ]

Fixed: https://github.com/gradle/gradle/commit/65be2c0cf1be6fa72b4354cab8e39d95fd42949a

The gradleApi() dependency now also contains the runtime dependencies for GradleLauncher.

Comment by Adam Murdoch [ 21/Jun/11 ]

GradleLauncher is a deprecated API, so you should avoid using it.

Supported alternatives are ProjectBuilder and the Tooling API. If needed, we can grow out ProjectBuilder to handle more testing use cases.

Comment by Luke Daley [ 29/Jun/11 ]

I've reverted the changes made to support this and am reopening this issue.

Comment by Luke Daley [ 29/Jun/11 ]

Renaming this issue to more accurately reflect the new goal.

Comment by Justin Ryan [ 01/Jun/12 ]

ProjectBuilder does provide a Project data structure, which can be used to some extent to test a plugin, but only to do a "project.apply plugin: 'myplugin'". Which can be useful for unit tests.

From what I can tell it's completely inadequate to test the full lifecycle, e.g. I want to see my afterEvaluate execute which can't happen if I just ProjectBuilder.builder().withProjectDir(projectDir).build() and make references to the Project. Ideally I could walk the Project through it's lifecycle:

  1. Create Project
  2. Configure via code, project.apply
  3. Run configure phase
  4. check Values
  5. Execute a task
  6. Check results

Or am I missing something? I really like the internal integration code in Gradle. Even if its not released directly, it's a model for what should be offered to plugin developers. This is a significant pain point in writing plugins.

Comment by Iain [ 10/May/14 ]

I share the same challenges as Ryan. Unit tests are all passing, but once my plugin is packaged and I attempt to use it I find integration errors. It would be great to find these earlier in the development cycle.

Comment by Adam Murdoch [ 26/Jul/15 ]

Luke Daley: can we close this now, with fix for 2.6-rc-1?

Comment by Luke Daley [ 04/Aug/15 ]

It took 4 years, and I had to join the project to get this fixed, but it is done

Generated at Wed Jun 30 12:00:10 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.