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
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.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
