On 1/24/06, Brett Porter <[EMAIL PROTECTED]> wrote:
> jerome lacoste wrote:
> I'm big on interfaces for defining and maintaining a simple public
> contract of the API,
They help to some extent, but if you are going to use interface just
to define your public contract, I think it might be an overus
jerome lacoste wrote:
> Exec was deemed to be an object that makes it easy to use the Executor
> for simple use cases, while Executor was more flexible.
Ok. The names could be better :)
> I'd rather have implementations then we add an interface in a later
> version if we need a remote exec.
>
>
> > Proposed architecture
> > - Launchers: exist as today
> > - OS functionality
> > - ProcessLauncher, (our ProcessBuilder)
> > - Execute (or Executor?): Flexible, we use it to tie together the
> > various concepts in the execute() call (stream management, process
> > management, process building,
jerome lacoste wrote:
> [Sorry for the long mail. I hope I was clear enough this time]
Crystal. Just took 4 months to read :)
> Current commons-exec features
>
>
> It
> - starts commands in the various platforms and SDK. Todays that's the
> launcher p
On 10/9/05, Niklas Gustavsson <[EMAIL PROTECTED]> wrote:
> Hi
> > We regard to my other patches, they can be discarded if we go for a
> > rewrite (through refactorings). Trygve: in particular the serializable
> > patch is not critical. Was just there to maintain the functionality of
> > the old API
Hi
Your mail was very insightful! I'm going to focus on a few points and
will probably get back on other parts later.
jerome lacoste wrote:
[snip]
There's a certain legacy in the current commons-exec and it shows a
lot. The main issue is the following: commons-exec as today was
written to s
[Sorry for the long mail. I hope I was clear enough this time]
This complements/summarizes the couple of mails I sent this week-end,
trying to give a better description of the vision I have for
commons-exec.
I don't want to impose anything. A library like commons-exec is
something I have been thi
