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