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
> [email protected]
> (mailto:[email protected])
> 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-tp5712028p5712033.html
Sent from the gradle-dev mailing list archive at Nabble.com.
