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-tp5712028p5712059.html Sent from the gradle-dev mailing list archive at Nabble.com.
