You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Brett Porter <br...@apache.org> on 2006/01/13 00:26:20 UTC
[exec] API sketch?
Hi,
Back in September 05 (wow, is it really 2006 already? :) Jerome sent a
comprehensive vision for exec. I found myself agreeing with most
everything in there (I'll reply to a couple of specifics shortly).
Message ID from then: <5a...@mail.gmail.com>
However, it was long and wordy. I think the key part was that "we should
have a minimal exposed API". Maybe a good step forward is to sketch that
API, then write implementations that reuse existing code, then refactor
code behind the scenes later?
With this, we could get something up and working *reasonably* quickly
that is *reasonably* stable.
Jerome, Niklas, Trygve - anyone interested in picking this up? In some
ways the above email described it and this is just an interface sketch.
Thanks,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] API sketch?
Posted by jerome lacoste <je...@gmail.com>.
On 1/13/06, Brett Porter <br...@apache.org> wrote:
> Hi,
>
> Back in September 05 (wow, is it really 2006 already? :) Jerome sent a
> comprehensive vision for exec. I found myself agreeing with most
> everything in there (I'll reply to a couple of specifics shortly).
>
> Message ID from then: <5a...@mail.gmail.com>
>
> However, it was long and wordy. I think the key part was that "we should
> have a minimal exposed API". Maybe a good step forward is to sketch that
> API, then write implementations that reuse existing code, then refactor
> code behind the scenes later?
BTW, I had implemented my proposal (refactoring the original code) and
the main API looked a lot like what was discussed in this thread.
Unfortunately, since I write it, I've had 2 disk failures, so I am not
sure that code is still accessible.
I will try to dig it up to compare it to the API proposed by Niklas.
Jerome
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] API sketch?
Posted by Brett Porter <br...@apache.org>.
jerome lacoste wrote:
> There's only one issue: backward compatibility. I have over 1000 lines
> of code that use the former API. So if the switch could be not too
> hard to do...
Use the IntelliJ Migration assistant :)
Seriously - I'd say here we should strive for biut not be constrained by
backwards compatibility (ie, let's clean up the API where it makes
sense, but not change things for the sake of it).
Maybe even have a deprecated old interface that wraps a new implementation.
I'll follow on the rest of the threads....
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] API sketch?
Posted by jerome lacoste <je...@gmail.com>.
On 1/17/06, Niklas Gustavsson <ni...@protocol7.com> wrote:
> Hi
>
> jerome lacoste wrote:
> > I had some changes in mind compared to my original design proposal, to
> > make it simpler.
> >
> > So I am willing to help you design & test this API/implementation and
> > make sure it works with CruiseControl.
>
> Great!
>
> > I don't want to duplicate efforts so I would prefer a coordinator on
> > that. Should I take back my original proposal and clean it up? Should
> > we start from scratch?
>
> I'll be happy to coordinate the efforts here. Did you have time to look
> at the quick draft I sent out last week in this thread?
>
> When it comes to designing the API I would be happy to start from
> scratch if that makes it any easier for the users of the library. I
> think we should strive for a simple API, in line with the XOM design
> principles [1]. I especially would like us to follow "As simple as it
> can be and no simpler", "There's exactly one way to do it" and "Do not
> allow clients to do bad things". I don't think the current code fits
> with any of these so there is some work to be done.
I agree with the principles.
There's only one issue: backward compatibility. I have over 1000 lines
of code that use the former API. So if the switch could be not too
hard to do...
> > Whatever the proposal, I want to see code examples to see how it would
> > work in practise.
>
> Agreed, what would be the requirements for use within CC?
More or less what was covered in my original API description document.
My current need is to:
- externalize the current Process execution to your library (reduce code in CC)
- get more control on the spawned processes to be able to give the
user a chance to kill them when something goes wrong.
J
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] API sketch?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Hi
jerome lacoste wrote:
> I had some changes in mind compared to my original design proposal, to
> make it simpler.
>
> So I am willing to help you design & test this API/implementation and
> make sure it works with CruiseControl.
Great!
> I don't want to duplicate efforts so I would prefer a coordinator on
> that. Should I take back my original proposal and clean it up? Should
> we start from scratch?
I'll be happy to coordinate the efforts here. Did you have time to look
at the quick draft I sent out last week in this thread?
When it comes to designing the API I would be happy to start from
scratch if that makes it any easier for the users of the library. I
think we should strive for a simple API, in line with the XOM design
principles [1]. I especially would like us to follow "As simple as it
can be and no simpler", "There’s exactly one way to do it" and "Do not
allow clients to do bad things". I don't think the current code fits
with any of these so there is some work to be done.
> Whatever the proposal, I want to see code examples to see how it would
> work in practise.
Agreed, what would be the requirements for use within CC?
/niklas
[1] http://www.xom.nu/designprinciples.xhtml
-------
Niklas Gustavsson
http://www.protocol7.com
mailto:niklas@protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] API sketch?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Hi
jerome lacoste wrote:
> I had some changes in mind compared to my original design proposal, to
> make it simpler.
>
> So I am willing to help you design & test this API/implementation and
> make sure it works with CruiseControl.
Great!
> I don't want to duplicate efforts so I would prefer a coordinator on
> that. Should I take back my original proposal and clean it up? Should
> we start from scratch?
I'll be happy to coordinate the efforts here. Did you have time to look
at the quick draft I sent out last week in this thread?
When it comes to designing the API I would be happy to start from
scratch if that makes it any easier for the users of the library. I
think we should strive for a simple API, in line with the XOM design
principles [1]. I especially would like us to follow "As simple as it
can be and no simpler", "There’s exactly one way to do it" and "Do not
allow clients to do bad things". I don't think the current code fits
with any of these so there is some work to be done.
> Whatever the proposal, I want to see code examples to see how it would
> work in practise.
Agreed, what would be the requirements for use within CC?
/niklas
[1] http://www.xom.nu/designprinciples.xhtml
-------
Niklas Gustavsson
http://www.protocol7.com
mailto:niklas@protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] API sketch?
Posted by jerome lacoste <je...@gmail.com>.
On 1/13/06, Brett Porter <br...@apache.org> wrote:
> Hi,
>
> Back in September 05 (wow, is it really 2006 already? :) Jerome sent a
> comprehensive vision for exec. I found myself agreeing with most
> everything in there (I'll reply to a couple of specifics shortly).
>
> Message ID from then: <5a...@mail.gmail.com>
>
> However, it was long and wordy. I think the key part was that "we should
> have a minimal exposed API". Maybe a good step forward is to sketch that
> API, then write implementations that reuse existing code, then refactor
> code behind the scenes later?
>
> With this, we could get something up and working *reasonably* quickly
> that is *reasonably* stable.
>
> Jerome, Niklas, Trygve - anyone interested in picking this up? In some
> ways the above email described it and this is just an interface sketch.
Cool. I was coming back to this subject now as I am more or less done
with my other things that took my away for the last 3 months.
I had some changes in mind compared to my original design proposal, to
make it simpler.
So I am willing to help you design & test this API/implementation and
make sure it works with CruiseControl.
I don't want to duplicate efforts so I would prefer a coordinator on
that. Should I take back my original proposal and clean it up? Should
we start from scratch?
Whatever the proposal, I want to see code examples to see how it would
work in practise.
Jerome
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] API sketch?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Brett Porter wrote:
> Niklas Gustavsson wrote:
>> /*
>> * StreamHandlers are used for providing input,
>> * retriving the output. Also used for logging.
>> */
>> StreamHandler getStreamHandler();
>> void setStreamHandler(StreamHandler streamHandler);
>
> My only comments on these is that I don't see the point of the setters
> in the interface - is it a requirement of the use of the library, or is
> it an implementation detail? (eg, I use plexus which instantiates
> objects implementations with private field injection, some use setters
> through reflection, some through a constructor - I'm not sure the
> interface requires it).
>
> As for the stream handler - what is the contents of that interface? Does
> it have an input, output and error stream?
>
In this sketch, the StreamHandler provide the streams for in, out and
err. There are some examples of StreamHandlers in the current code.
In one way or another this functionality would be required in the API.
> You have commit access now, so if you want to start writing some example
> code (or create a fresh branch, even), you're welcome to.
Yeah, I know. Just wanted to get some input here before getting going :-)
/niklas
-------
Niklas Gustavsson
http://www.protocol7.com
mailto:niklas@protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] API sketch?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Brett Porter wrote:
> Niklas Gustavsson wrote:
>> /*
>> * StreamHandlers are used for providing input,
>> * retriving the output. Also used for logging.
>> */
>> StreamHandler getStreamHandler();
>> void setStreamHandler(StreamHandler streamHandler);
>
> My only comments on these is that I don't see the point of the setters
> in the interface - is it a requirement of the use of the library, or is
> it an implementation detail? (eg, I use plexus which instantiates
> objects implementations with private field injection, some use setters
> through reflection, some through a constructor - I'm not sure the
> interface requires it).
>
> As for the stream handler - what is the contents of that interface? Does
> it have an input, output and error stream?
>
In this sketch, the StreamHandler provide the streams for in, out and
err. There are some examples of StreamHandlers in the current code.
In one way or another this functionality would be required in the API.
> You have commit access now, so if you want to start writing some example
> code (or create a fresh branch, even), you're welcome to.
Yeah, I know. Just wanted to get some input here before getting going :-)
/niklas
-------
Niklas Gustavsson
http://www.protocol7.com
mailto:niklas@protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] API sketch?
Posted by Brett Porter <br...@apache.org>.
Niklas Gustavsson wrote:
> /*
> * StreamHandlers are used for providing input,
> * retriving the output. Also used for logging.
> */
> StreamHandler getStreamHandler();
> void setStreamHandler(StreamHandler streamHandler);
My only comments on these is that I don't see the point of the setters
in the interface - is it a requirement of the use of the library, or is
it an implementation detail? (eg, I use plexus which instantiates
objects implementations with private field injection, some use setters
through reflection, some through a constructor - I'm not sure the
interface requires it).
As for the stream handler - what is the contents of that interface? Does
it have an input, output and error stream?
You have commit access now, so if you want to start writing some example
code (or create a fresh branch, even), you're welcome to.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] API sketch?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Hi
Brett Porter wrote:
> Hi,
>
> Back in September 05 (wow, is it really 2006 already? :) Jerome sent a
> comprehensive vision for exec. I found myself agreeing with most
> everything in there (I'll reply to a couple of specifics shortly).
>
> Message ID from then: <5a...@mail.gmail.com>
>
> However, it was long and wordy. I think the key part was that "we should
> have a minimal exposed API". Maybe a good step forward is to sketch that
> API, then write implementations that reuse existing code, then refactor
> code behind the scenes later?
>
> With this, we could get something up and working *reasonably* quickly
> that is *reasonably* stable.
>
> Jerome, Niklas, Trygve - anyone interested in picking this up? In some
> ways the above email described it and this is just an interface sketch.
I think getting a very clear and simple API working would be an
excellent next step. Given such an API, we can refactor Execute and Exec
to fit the API. Here's a quick stab at a first proposal for a new
Execute class:
/*
* StreamHandlers are used for providing input,
* retriving the output. Also used for logging.
*/
StreamHandler getStreamHandler();
void setStreamHandler(StreamHandler streamHandler);
/*
* Watchdog is used to kill of processes running,
* typically, to long time.
*/
ExecuteWatchdog getWatchdog();
void setWatchdog(ExecuteWatchdog watchDog);
File getWorkingDirectory();
void setWorkingDirectory(File dir);
/*
* Methods for starting synchronous execution.
* Returns process exit value
*/
int execute(String[] command) throws ExecuteException;
int execute(String[] command, Map environment) throws ExecuteException;
/*
* Methods for starting asynchronous execution. Result provided to
callback handler
*/
void execute(String[] command, ExecuteResultHandler handler) throws
ExecuteException;
void execute(String[] command, Map environment, ExecuteResultHandler
handler) throws ExecuteException;
Besides this API, I think we should provide utility classes for
retrieving the current Environment. I also think we should get rid of
the current environment classes and use a Map instead. This simplifies
working with our API and gets us inline with the Java 1.5 environment
support.
/niklas
-------
Niklas Gustavsson
http://www.protocol7.com
mailto:niklas@protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [exec] API sketch?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Hi
Brett Porter wrote:
> Hi,
>
> Back in September 05 (wow, is it really 2006 already? :) Jerome sent a
> comprehensive vision for exec. I found myself agreeing with most
> everything in there (I'll reply to a couple of specifics shortly).
>
> Message ID from then: <5a...@mail.gmail.com>
>
> However, it was long and wordy. I think the key part was that "we should
> have a minimal exposed API". Maybe a good step forward is to sketch that
> API, then write implementations that reuse existing code, then refactor
> code behind the scenes later?
>
> With this, we could get something up and working *reasonably* quickly
> that is *reasonably* stable.
>
> Jerome, Niklas, Trygve - anyone interested in picking this up? In some
> ways the above email described it and this is just an interface sketch.
I think getting a very clear and simple API working would be an
excellent next step. Given such an API, we can refactor Execute and Exec
to fit the API. Here's a quick stab at a first proposal for a new
Execute class:
/*
* StreamHandlers are used for providing input,
* retriving the output. Also used for logging.
*/
StreamHandler getStreamHandler();
void setStreamHandler(StreamHandler streamHandler);
/*
* Watchdog is used to kill of processes running,
* typically, to long time.
*/
ExecuteWatchdog getWatchdog();
void setWatchdog(ExecuteWatchdog watchDog);
File getWorkingDirectory();
void setWorkingDirectory(File dir);
/*
* Methods for starting synchronous execution.
* Returns process exit value
*/
int execute(String[] command) throws ExecuteException;
int execute(String[] command, Map environment) throws ExecuteException;
/*
* Methods for starting asynchronous execution. Result provided to
callback handler
*/
void execute(String[] command, ExecuteResultHandler handler) throws
ExecuteException;
void execute(String[] command, Map environment, ExecuteResultHandler
handler) throws ExecuteException;
Besides this API, I think we should provide utility classes for
retrieving the current Environment. I also think we should get rid of
the current environment classes and use a Map instead. This simplifies
working with our API and gets us inline with the Java 1.5 environment
support.
/niklas
-------
Niklas Gustavsson
http://www.protocol7.com
mailto:niklas@protocol7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org