Good stuff John,
I'll take a look at it and leave any applicable comments on GitHub.
One output of this work that I'd like to see is a design spec for the
work that needs to happen in the core to make this better supported.
Your plugin will be illuminating for that.
--
Luke Daley
Principal Engineer
http://gradleware.com
On 5 Dec 2013, at 13:07, johnrengelman wrote:
I went ahead and implemented an initial version of this entirely as a
plugin. It ends up relying on some internal classes for a couple
things (mainly an enum that indicates the process state). If this
looks good, we could promote that class in core in be public instead
of internal OR I could add a new enum in the plugin that wraps the
internal enum to a public one.
Here it is: https://github.com/johnrengelman/gradle-processes
It's available on JCenter.
--
John Engelman
On Tuesday, November 26, 2013 at 9:14 AM, John Engelman wrote:
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-tp5712028p5712101.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
