On 31/07/2011, at 12:53 AM, Ladislav Thon wrote: > Hi, > > since GradleLauncher was deprecated in 1.0-m3, I'm trying to rewrite some > code to use the Tooling API (actually, the code is a small integration test > suite for Gradle Android Plugin). And I found out that it is probably > expected that the buildscript will be always named "build.gradle"; or, put > another way, I can't specify which buildscript should the Tooling API use. I > can specify the project directory, but not the buildscript file (as was > possible with GradleLauncher setting StartParameter.buildFile property). > > Am I correct with this or not? If yes, will this be possible?
It's not possible yet, but will be. All of the stuff you can do with GradleLauncher will be available at some point, either through the tooling api or through a test fixture. One option is to add something like BuildLauncher.forCommandLineArgs(String...) as a catch-all solution. We'll need this at some point. However, this is a version dependent solution (ie you have to know the appropriate command-line option for the target Gradle version), plus it doesn't help if you want to build a model for the build. Another option is to add GradleConnector.forBuildScript(File script), which would allow you to create a ProjectConnection for building the model and running builds. Another option is to create a test fixture and add the support for command-line args and/or build script there. I'd like a fixture that extends the tooling API to add test capabilities and extra stuff. This way, the tests can make use of things we add to the tooling API, plus we can hoist things up from the test fixture to the tooling API if they prove to be generally useful. > I was digging in the source code and found the ConfiguringBuildAction class, > which is probably responsible for filling StartParameter in the Tooling API. > I might be able to hack the support myself, but I'm not familiar with these > Tooling API versions and protocol and stuff, so I figured I would ask first. There are some layers in there to deal with the forwards and backwards compatibility, and so it's currently a bit of work to add stuff to the API. We've been simplifying this to make it easier to add stuff coming out of the tooling API, but haven't done so for stuff going in, as we haven't needed to yet. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
