Please, provide possibility to forbid reseting InputOutput:

ExecutionService.configureInputOutput(InputOutput inputOutput) {
        try {
            inputOutput.getOut().reset();
        } catch (IOException exc) {
            LOGGER.log(Level.INFO, null, exc);
        }
....

This lack of functionality does not allow CND migrate to org.netbeans.api.extexecution API.

I don't work on extexecution.

It might be ease to do such enhancement technically. However I would like to know more details about your use case. Do you use your own InputOutput or one provided by default? Please be as abstract as possible (I do not know much about cnd).

Such configuration parameter could bias the API. As it could be potentially dangerous to provide an option to don't reset output for output windows managed by infrastructure which are reused by name...

Some cnd actions consist from several steps (for example: clean and build).
Such actions implemented as several executable calls (for example: make clean and make build).
Old cnd executor use following logic:
- create or reuse existent InputOutput by IOProvider.getDefault().getIO(name, false), where name is project name+"(Clean, Build)"+host name. So cnd reuse same tab for each concrete project building.
- reset InputOutput
- execute make clean without reset InputOutput
- execute make build without reset InputOutput
As result tab content will consist from both logs (clean and build).

New execution API does not allow reuse InputOutput in second step without resetting.
It is a big regression from cnd point of view.

So my suggestion:
If InputOutput exists before ExecutionService.run() and ExecutionDescriptor has property doNotResetInputOutput the ExecutionService.run() does not reset InputOutput.

Alternative:
Change API of InputOutput:
- add method reset and remove reseting from OutputWriter
It allows user to create proxy of InputOutput with own resetting.

From cnd point of view it is API defect.

IMHO resetting of InputOutput is not responsibility of ExecutionService.

to refine Alexander's suggestion:
- if client specify directly own IO => remember this as internal state resetInputOutput=false
- reset io based on resetInputOutput

I'll try to avoid resetting with custom io (this will change API behavior and may broke clients who expect this). Would it be enough?

Definitely no a defect. Defect can't be something you've expected working different way (unless there is a clash in documented and real behavior).

(In reply to comment #5)
> Alternative:
> Change API of InputOutput:
> - add method reset and remove reseting from OutputWriter
> It allows user to create proxy of InputOutput with own resetting.

This is IMHO doable even now as InputOutput is interface and OutputWriter is abstract class you can wrap the InputOutput and OutputWriter to delegete all methods to original ones while doing nothing on reset.

>This is IMHO doable even now as InputOutput is interface and OutputWriter is
>abstract class you can wrap the InputOutput and OutputWriter to delegete all
>methods to original ones while doing nothing on reset.
Not doable due to implementation of OutputWriter. Only own implementation of OutputWriter without delegate is possible.

>I'll try to avoid resetting with custom io (this will change API behavior and
>may broke clients who expect this). Would it be enough?
It is enough.

>Definitely no a defect. Defect can't be something you've expected working
>different way (unless there is a clash in documented and real behavior).
It is defect because client do not expect that run will clean ouutput tab.
Do you expect that command ls will clean terminal?
It is a same situation. Client prepared InputOutput and do not expect that run will clean tab.

It is just your opinion based on personal expectations. Unless ls will state in doc "I won't ever clear terminal" it can. Maybe I wouldn't like it so I would file an enhancement to not to clear the terminal as I would think it is good. But I can't argue it is a defect.

Otherwise every enhancement in API would be qualified as defect in case there is >=1 persons who feel it should work different way.

By the way it is defect/regression for cnd users (11% of all NB users).

You replaced (or wrote some new, I don't know) feature with extexecution without validating it is doing what you want/expect. So now rather than asking for enhancement (or even better contributing patch+test) you are blaming the API? With statements like: "It is regression for our users". Not a fault of the API.

This discussion is pretty much useless, consuming my time while I'm trying to implement the enhancement.

(In reply to comment #12)
> It is defect because client do not expect that run will clean ouutput tab.

I disagree, exactly this behaviour would be a defect for us (PHP). If I rerun a task (script), I expect that I will see the output of exactly one task (like it is now and has always been).

> Do you expect that command ls will clean terminal?
> It is a same situation. Client prepared InputOutput and do not expect that run
> will clean tab.

IMHO it's not, ExtExecution API != terminal.

Please review the change. It makes the reset optional (but enabled by default to keep the compatibility) for client managed IO. For infrastructure managed IO the behavior is not changed in any way.

Created attachment 94038 [details]
the patch

(In reply to comment #15)
> You replaced (or wrote some new, I don't know) feature with extexecution
> without validating it is doing what you want/expect. So now rather than asking
> for enhancement (or even better contributing patch+test) you are blaming the
> API? With statements like: "It is regression for our users". Not a fault of the
> API.
> 
> This discussion is pretty much useless, consuming my time while I'm trying to
> implement the enhancement.

Petr, sorry if I hurt you it wasn't my intention. And thanks for the quick implementation of ENH.

I'll integrate the change tomorrow.

Fixed in web-main #41d5a0f1bef2.

Integrated into 'main-golden', will be available in build *201002180200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/41d5a0f1bef2
User: phejl@netbeans.org
Log: #180459 Optional reset of InputOutput in extexecution

Petr, thanks for the fix. It works!

Integrated into 'main-golden', will be available in build *201002220200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/682120e4665a
User: alexvsimon@netbeans.org
Log: fixed CND part of BZ#180459 Optional reset of InputOutput in extexecution