Add Buildship (Gradle plugin for Eclipse) integration

[missedone]

with feature #193 , M2E integration was supported, similarly, we can build the Buildship integration for Gradle plugin, so that when launching the test via gradle test, the argLine and/or system properties will be appended to the testng process.

the challenges:

1. gradle organize the tasks, properties in script, rather like maven uses pom.xml which is easier for parsing with code. we need to figure out a way to get the argLine, system properties etc. out of the gradle test pluign

[missedone]

since Gradle build file is groovy script, which is hard for interpret in term of retrieving the configuration info, rather than Maven, the pom.xml is declarative that easy for machine to go through the model. So, to get the configuration info from Gradle, the idea is to create TestNG Gradle plugin to hook into Gradle test plugin lifecycle, to read the configuration of JVM args, system properties, env vars, etc. and write them into a tmp file (probably located under the project), the file will be updated every time Buildship sync the Gradle project. with this file, the new TestNG Buildship integration Eclipse plugin can read the file and passed them to the testng runtime process.

[ben-manes]

Gradle expects consumers to go through the tooling api rather than interpret the script. You may be able to get all of the information you need without a custom plugin.

[missedone]

thanks for the tips, that's exactly what I need.

[oehme]

so that when launching the test via gradle test, the argLine and/or system properties will be appended to the testng process.

I assume you meant "When launching via a TestNG run configuration"? For that use case, @ben-manes has already pointed out the right way to go - getting the configuration you need through the Tooling API.

But there is another way to think about testing integration:

Buildship already has a Run as Gradle Test feature which calls gradle test under the hood. The benefit of this (over a TestNG or JUnit launch config) is that all necessary setup/teardown Gradle tasks are also run. The test listeners that the user registered in Gradle are called, build scans can be created etc. In short, the user gets exactly the same result as when he runs tests from the command line.

This is how we want to handle IDE integration in general - getting away from framework-specific run configurations and using Gradle to do the heavy lifting instead. Running tests this way already works nicely, debugging is still an open issue, but would not be too hard to implement. We'd warmly welcome contributions in that area.

[missedone]

thanks @oehme for your valueable input.

The test listeners that the user registered in Gradle are called, build scans can be created etc. In short, the user gets exactly the same result as when he runs tests from the command line.

this is also what I'd like to achieve, recently I was thinking try to make it happen on Maven integration first, issue #314 makes me think it twice.

Running tests this way already works nicely, debugging is still an open issue, but would not be too hard to implement.

Indeed, though I don't have bright thought at the moment, the first thing come out of mind is with remote debugging, both Maven and Gradle have option to enable remote debug on port 5005. (mvn -Dmaven.surefire.debug test, gradle test --debug)

[oehme]

Exactly, remote debugging would be the way to go (using --debug-jvm)