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 that the build can wait on a process later. > > As for state, I've exposed the process state from the current > > execution but I haven't looked at anything that would allow for > > process state between gradle executions (i.e. I'm thinking something > > like a 'gradle start' that forks a process and a 'gradle stop' that > > ends it, somehow finding the right process and terminating it). My > > feeling there is that somehow getting the PID for the process and > > dropping it into the build/ directory would be the best option. But > > that's step 3. > > Step 2, would be to expose the public interface > > (AsyncProcessOperations) through an extension on the project. > It would be better to do this work external to the Gradle codebase to > incubate it. I don't see a reason why this couldn't start life as an > external plugin and then move in (if necessary) when we understand the > requirements more. > > I also think it would get more contributions this way as it's easier to > contribute to a Gradle plugin project than the Gradle core codebase. > > > > > I was thinking that adding a plugin that adds an extension that > > extends the AsyncProcessOperations interface would work, thoughts? > > > > -- > > John Engelman > > > > > > On Thursday, November 21, 2013 at 10:34 AM, John Engelman 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 the extension to the project only when you apply > >> it. > >> > >> Yeah, I suspected I would need to create a new interface in > >> org.gradle.process to expose the functionality needed. Probably leave > >> ExecHandle where it is to limit the impact. > >> > >> -- > >> John Engelman > >> > >> > >> On Thursday, November 21, 2013 at 10:16 AM, Luke Daley-2 [via Gradle] > >> wrote: > >> > >>> > >>> On 21 Nov 2013, at 3:11 pm, johnrengelman <[hidden email] > >>> (/user/SendEmail.jtp?type=node&node=5712031&i=0)> wrote: > >>> > >>>> Hi all - > >>>> I've been finding more and more reasons in our build in our build > >>>> to create > >>>> an implementation of java process forking. Currently the JavaExec > >>>> implementation is synchronous and I'm looking at implementing some > >>>> features > >>>> that would allow a build to fork multiple processes and then > >>>> blocking on > >>>> joining them back together. I don't see any designDocs related to > >>>> this (or > >>>> to parallel task execution within a project) so I wonder if there > >>>> is some > >>>> thought already on this. > >>>> > >>>> I have a working implementation that I want to extend into gradle > >>>> core if > >>>> possible. The simple API would be to add the following to Project: > >>>> > >>>> ExecHandle javafork(Closure closure); > >>>> ExecHandle fork(Closure closure); > >>>> > >>>> Might also be useful to add the following: > >>>> > >>>> ExecResult join(ExecHandle handle); > >>>> List<ExecResult> join(List<ExecHandle> handles); > >>>> > >>>> Any thoughts or suggestions? > >>> ExecHandle is currently internal API, so at the least that would > >>> have to be addressed. > >>> > >>> Another problem is that we are really reluctant to grow the Project > >>> API at all. We are working on a way to add new functionality like > >>> this, but it's not going to be available soon. It would be > >>> preferable to deliver this as a kind of extension library for the > >>> time being. It will have to use internal API so that does mean there > >>> may be versioning issues. > >>> > >>> In my experience when working with async processes, you nearly > >>> always end up doing some pattern matching on the launched process > >>> for state control. It would be good to get some support for that in > >>> there too. > >>> > >>> -- > >>> Luke Daley > >>> Principal Engineer, Gradleware > >>> http://gradleware.com > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe from this list, please visit: > >>> > >>> http://xircles.codehaus.org/manage_email > >>> > >>> > >>> > >>> > >>> If you reply to this email, your message will be added to the > >>> discussion below: > >>> http://gradle.1045684.n5.nabble.com/ForkedJavaExec-implementation-tp5712028p5712031.html > >>> To start a new topic under gradle-dev, email > >>> [hidden email] (/user/SendEmail.jtp?type=node&node=5712056&i=0) > >>> (mailto:[hidden email] (/user/SendEmail.jtp?type=node&node=5712056&i=1)) > >>> To unsubscribe from gradle-dev, click here > >>> ( > >>> NAML > >>> (http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml) > >>> > >> > > > > > > > > > > > > -- > > View this message in context: > > http://gradle.1045684.n5.nabble.com/ForkedJavaExec-implementation-tp5712028p5712037.html > > Sent from the gradle-dev mailing list archive at Nabble.com > > (http://Nabble.com). > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > > > If you reply to this email, your message will be added to the discussion > below: > http://gradle.1045684.n5.nabble.com/ForkedJavaExec-implementation-tp5712028p5712056.html > > To start a new topic under gradle-dev, email > ml-node+s1045684n1436218...@n5.nabble.com > (mailto:ml-node+s1045684n1436218...@n5.nabble.com) > To unsubscribe from gradle-dev, click here > (http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1436218&code=am9obi5yLmVuZ2VsbWFuQGdtYWlsLmNvbXwxNDM2MjE4fDIyMTUyNjEzNQ==). > NAML > (http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml) > -- View this message in context: http://gradle.1045684.n5.nabble.com/ForkedJavaExec-implementation-tp5712028p5712057.html Sent from the gradle-dev mailing list archive at Nabble.com.
