Submitted pull request with design spec for changes:
https://github.com/gradle/gradle/pull/229
--
John Engelman
On Monday, December 9, 2013 at 3:34 PM, Luke Daley-2 [via Gradle] wrote:
>
> > Sounds good.
> >
> > Would you like me to submit the design spec to Gradle Core with that
> >
Sounds good.
Would you like me to submit the design spec to Gradle Core with that same
format?
--
John Engelman
On Monday, December 9, 2013 at 12:06 PM, Luke Daley-2 [via Gradle] wrote:
> Good stuff John,
>
> I'll take a look at it and leave any applicable comments on GitHub.
>
>
I went ahead and implemented an initial version of this entirely as a plugin.
It ends up relying on some internal classes for a couple things (mainly an enum
that indicates the process state). If this looks good, we could promote that
class in core in be public instead of internal OR I could add
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
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:
>
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 just a break up of what is currently
there so th
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
the extension to the project only when you apply it.
