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. > > One output of this work that I'd like to see is a design spec for the > work that needs to happen in the core to make this better supported. > Your plugin will be illuminating for that. > > -- > Luke Daley > Principal Engineer > http://gradleware.com > On 5 Dec 2013, at 13:07, johnrengelman wrote: > > > 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) > >>>>>> (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) > >>>> (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 > >>> [hidden email] (/user/SendEmail.jtp?type=node&node=5712107&i=0) > >>> (mailto:[hidden email] (/user/SendEmail.jtp?type=node&node=5712107&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-tp5712028p5712101.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-tp5712028p5712107.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-tp5712028p5712108.html Sent from the gradle-dev mailing list archive at Nabble.com.
