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 a new enum in the plugin that wraps the internal enum to a public one.
Here it is: https://github.com/johnrengelman/gradle-processes It's available on JCenter. -- John Engelman On Tuesday, November 26, 2013 at 9:14 AM, John Engelman wrote: > 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 API > 2) Move ExecHandleState from internal API to public API. Rename to be > ProcessState > 3) Add boolean isIgnoreExitValue to DefaultExecHandle. Initialize with value > from AbstractExecHandleBuilder (this gives me the ignoreExitValue state on > the ProcessHandle, for checking later) > > I think those are the only ones that should really go into core. They > shouldn't have any impact on any other code. > > Additionally there are definitions for: ForkAction (based on ExecAction), > JavaForkAction, DefaultJavaForkAction, DefaultForkAction that I originally > had in core, but they could live in a plugin for now (although they'll be > extending internal classes and APIs) > > How does that sound? > > -- > John Engelman > > > On Tuesday, November 26, 2013 at 9:05 AM, Luke Daley-2 [via Gradle] wrote: > > > > > > > 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 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) > > >>> (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 > > >> [hidden email] (/user/SendEmail.jtp?type=node&node=5712058&i=0) > > >> (mailto:[hidden email] (/user/SendEmail.jtp?type=node&node=5712058&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-tp5712028p5712057.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-tp5712028p5712058.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-tp5712028p5712101.html Sent from the gradle-dev mailing list archive at Nabble.com.
