[exec] design goals, API sketch, etc.. next step?

[jerome lacoste <je...@gmail.com>]

    Niklas, Brett, Trygve & all,


Things were stagnating a little bit end of last year. I am happy to
see that things are in motion again.

Last interesting initiative was Brett's idea to start with an API
sketch. I think it is a good start but it's only solving the start
Process feature. That's the low level building block. We ought to
provide more (otherwise we are just JDK 1.5 equivalent and that's not
interesting to me). See my past mails (expesially 'vision....') for
more info.


Below is a list of past emails that contain information relative to the subject.

[exec] Design of commons-exec
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/69584

I listed there a list of high level requirements that I want to keep
in mind when designing the library.



[exec] API, implementation various notes
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/72242

Those mails are maybe too long to read, if you can only read one, pick
the second in the thread. There I compared the various APIs (JD 1.4,
JDK 1.5, old common-exec). This is an important point to remember when
making the API sketch.

After those mails I refactored the existing commons-exec code
according to the vision I had proposed. I also did integrate the
refactored library into the CruiseControl code (which has about 30
code points that can make use of commons-exec).

The refactoring ended up here:

http://moca.dynalias.com/~jerome/projects/exec2/

(Unfortunately it seems like I messed up apache access rights, but I
should make this code available tomorrow).

[Someone told me at some point that I should send this refactoring as
a serie of patches. I can do it now if we think it is worth doing.]

This code is important to keep in mind. It keeps the past working
code, it has a cleaner interface (although not perfect) and it is
integrated with an existing project. To me it's better than an API
sketch (although the API sketch is a very nice complement, because it
is fresh and untangled).



After that I sent a mail based on my experience from the refactoring.

[exec] vision for the library
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/72295

(once again a long read...)


[Exec] API sketch
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/77425

And now the latest emails related to the new API sketch.




So here's what I propose to do:
- decide which requirements are important. What is the problem we are
trying to solve? How do we position us compared to the official's API?
etc... Someone using SDK 1.4 or 1.5 should find a compelling reason to
migrate to commons-exec. The migration should be intuitive. Benefits
for migrating clear. I think I exposed my ideas in the thread about
the library's vision.


- we compare the clean API sketch to the refactoring I made in
September. We focus on making this API easy to use and remember
without compromise on flexibility.

- we then take a decision on how to reach an implementation that
satisfies this API (Either start from the API sketch, or from the
refactorings I made 4 months ago).


I don't care on the approach as long as we get things moving and that
efforts are not wasted.

Niklas you said you could coordinate. I offered my help for coding,
documentation and tests. There's already a lot of work done on that.
Who else is interested? How do we proceed? Niklas I let you answer
those questions.

Let's try not to loose the momentum. I just don't want my efforts to
be wasted (so far they haven't been productive enough to my taste). I
would really like this library to be in early alpha by end of
February. So I can get it off the list of things I said I would do.


Cheers,

Jerome

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [exec] design goals, API sketch, etc.. next step?

[jerome lacoste <je...@gmail.com>]

On 1/24/06, Brett Porter <br...@apache.org> wrote:
> jerome lacoste wrote:
> > The refactoring ended up here:
> >
> > http://moca.dynalias.com/~jerome/projects/exec2/
> >
> > (Unfortunately it seems like I messed up apache access rights, but I
> > should make this code available tomorrow).
>
> Let us know, I'll take a look. I don't think I ever saw this...

Seems like trac URL rewriting is messing up with my file serving
functionality. I made an archive of the refactored package located at:

http://moca.dynalias.com/~jerome/commons-exec-refactored_09_2005.tar.bz2

J

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [exec] design goals, API sketch, etc.. next step?

[Brett Porter <br...@apache.org>]

jerome lacoste wrote:
> The refactoring ended up here:
> 
> http://moca.dynalias.com/~jerome/projects/exec2/
> 
> (Unfortunately it seems like I messed up apache access rights, but I
> should make this code available tomorrow).

Let us know, I'll take a look. I don't think I ever saw this...

> - decide which requirements are important. What is the problem we are
> trying to solve? How do we position us compared to the official's API?
> etc... Someone using SDK 1.4 or 1.5 should find a compelling reason to
> migrate to commons-exec. The migration should be intuitive. Benefits
> for migrating clear. I think I exposed my ideas in the thread about
> the library's vision.

Sounds good. My main requirements:
- be able to run an external command in a small number of lines,
capturing or streaming output and pass in my own input handler. Have it
actually work on Windows and Unix et al when there are quotes, spaces,
etc in the binary, arguments, etc.
- be able to run a process in the background, find out when it finished,
kill it if necessary.
- wire it up in an IoC container so I can do even less code to configure
it :)

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [exec] design goals, API sketch, etc.. next step?

[Niklas Gustavsson <ni...@protocol7.com>]

jerome lacoste wrote:
>     Niklas, Brett, Trygve & all,
> 
> 
> So here's what I propose to do:
> - decide which requirements are important. What is the problem we are
> trying to solve? How do we position us compared to the official's API?
> etc... Someone using SDK 1.4 or 1.5 should find a compelling reason to
> migrate to commons-exec. The migration should be intuitive. Benefits
> for migrating clear. I think I exposed my ideas in the thread about
> the library's vision.


Agreed, lets got through the requirements gathered so far (these are 
more of less copied from your's and Bretts email with some additions by 
myself).

* Provide an equivalent to ProcessBuilder working in older JREs
* Process and Stream management, allowing flexible reuse of this 
functionality
* be able to run an external command in a small number of lines,
capturing or streaming output and pass in my own input handler. Have it
actually work on Windows and Unix et al when there are quotes, spaces,
etc in the binary, arguments, etc.
* be able to run a process in the background, find out when it finished,
kill it if necessary.
* wire it up in an IoC container so I can do even less code to configure
it
* Provide an API for retrieving the current environment

Would you like anything else in there?

I think those listed above are covered by the current code, albeit 
behind an ugly API.

> - we compare the clean API sketch to the refactoring I made in
> September. We focus on making this API easy to use and remember
> without compromise on flexibility.

Agreed, I will check out your refactoring next.

> - we then take a decision on how to reach an implementation that
> satisfies this API (Either start from the API sketch, or from the
> refactorings I made 4 months ago).
> 
> 
> I don't care on the approach as long as we get things moving and that
> efforts are not wasted.
> 
> Niklas you said you could coordinate. I offered my help for coding,
> documentation and tests. There's already a lot of work done on that.
> Who else is interested? How do we proceed? Niklas I let you answer
> those questions.

Yeap, I'll try my best to coordinate the efforts. First of all, I would 
like us to agree on the initial requirements. From what I gather, I 
think our basic requirements are very similar so I don't expect this to 
be any problem.

I will also have a look at the refactoring you've made and get back with 
comments on that tomorrow.


> Let's try not to loose the momentum. I just don't want my efforts to
> be wasted (so far they haven't been productive enough to my taste). 

Agreed.

> I
> would really like this library to be in early alpha by end of
> February. So I can get it off the list of things I said I would do.


I think that is a reasonable goal.

/niklas


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org