I decided not to leak NetBeans internals into the Output window. That probably would have confused more people, than hiding those things, and again that would leak internals into the output window. I was planning to add an option, that could enable displaying the full command line, if there would be enough complaints.

Well, it turned out that it was the other way round: hiding confused the hell out of me :)

I'm not familiar with NB practices, but for me the whole point of logging is to expose internals. Error dialogs should give a user-friendly output, but logging is exactly for exposing internals in order to facilitate debugging.

Later on the "best effort" caused some misunderstanding when used with certain plugins, so we decided to deprecate "runSingle", encourage people to inspect and configure their build script right, instead of relying on NetBeans heuristics.

I assumed that "Run Single" and all other commands that are built into the IDE are an API that has to be implemented by the authors of a build system plugin (like Gradle or Maven). Deprecating this API might make it easier for plugin authors, but it will take a feature away from users.

Also, if there were conceptual difficulties implementing this API in an interoperable manner, then the same problems can be expected for users, if we ask them to implement the feature in their build scripts. If it were easy to implement in the build script, then surely there would be no conceptual problems coming up with a heuristic for the IDE.

As far as I can see, if I have 100 classes that I want to potentially run as "Run Single" or 3000 methods that I want to run as "Run focused test method", then I need to write 100 or 3000 tasks in the build script. The point is that as an IDE user I can click on a method or class and say "Run this" or "Test this". So the UI needs to pass the selected method or class to the build script. In which case it could easily output the generated gradlew (or mvn) command in the Output Window. We (users of an IDE) are all developers, too, and not easily confused by comprehensive output - more so, however, by incomplete output.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Reply via email to