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 > > same format? > > If you're up for it, that would be a great way to make this happen. > > > > > -- > > 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) > >>>>>>>> (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) > >>>>>> (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) > >>> (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 > >> [hidden email] (/user/SendEmail.jtp?type=node&node=5712109&i=0) > >> (mailto:[hidden email] (/user/SendEmail.jtp?type=node&node=5712109&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-tp5712028p5712108.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-tp5712028p5712109.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-tp5712028p5712113.html Sent from the gradle-dev mailing list archive at Nabble.com.
