On 21 Nov 2013, at 16:34, johnrengelman 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.
That would be the place to start.
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-tp5712028p5712033.html
Sent from the gradle-dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
