Sure. Mainly these are to get certain things from the internal API into a
public space with minimal impact.
1) Create ProcessHandle public API. Make ExecHandle (internal API) extend it.
Move getState(), waitForFinish(), getCommand(), getArguments(),
getEnvironment(), getDirectory() to public AP
On 26 Nov 2013, at 15:00, johnrengelman wrote:
That sounds good Luke.
I'll submit a PR for core for the changes I need in the next couple of
days and then start up a plugin project.
Can you outline the core changes you need before hand? I'd like to
minimise this at this point.
--
John
That sounds good Luke.
I'll submit a PR for core for the changes I need in the next couple of days and
then start up a plugin project.
--
John Engelman
On Tuesday, November 26, 2013 at 4:52 AM, Luke Daley-2 [via Gradle] wrote:
>
>
> On 22 Nov 2013, at 21:57, johnrengelman wrote:
>
On 22 Nov 2013, at 21:57, johnrengelman wrote:
This is my state at defining the API:
https://github.com/johnrengelman/gradle/commit/41c005e211c13237407db8ca031d8b215f9241c3
It does some work pulling apart the internal API for what makes sense
to expose through the public API. Most of it is
On 21 Nov 2013, at 16:34, johnrengelman wrote:
Could we add the functionality to the Project API through an extension
then?
Something like
project.extensions.async.javaFork { … } to get at it? Would that
help to separate it enough? I guess I write it as a separate plugin
entirely that adds
I'm going forward with #1 currently. I think it gives us a good starting
point to grow it further. Also, that's what most users expect I bet. Most
users think in implementation classes and methods and would be very happy
to execute tests based on matching class(es) and matching method(s). The
origi
