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 package. It's mostly good as is. > - retrieves os environment, determining on which os we are, etc.. > Today that's the OS class + environment package. > - builds a process (that's part of Execute) > - attaches stream and process operations around the execution of a > Process (still part of Execute). > - tries to provide good defaults for executing a process (hides > complexity of the Execute) (What Exec does today). > - should allow clients to make their own stream operations > (redirection, visitor-like patterns for consuming information, > etc...). Today exists but not that reusable. This should be helpful in sketching some API interfaces. > Commons-exec becomes a sort of (ProcessBuilder + advanced features) on > all SDK, all platforms. > > 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, etc...) > - Exec (or ??) makes it easy to use Execute/or. I'm missing the difference between Exec and Executor - but otherwise agree. > The architecture doesn't need to be very different from what it is today. > In fact I think it can be achieved by refactoring the current code. I like > that. I'd like to have some clean interfaces even if they are similar. I think we should use interfaces with an implementation so we can later do what Dion suggested at one point - a "remote exec" implementation. - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
