On 12/28/23 08:49, Ulrich Mayring wrote:
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 :)
Well, I'm sorry about that. Maybe you are not the first one since the
introduction of Gradle in NetBeans 11.0, but the first to raise his
voice about that.
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.
Well, the main concept used in Gradle for NetBeans is that is should be
no intrusive. In early days the IDEA and Eclipse plugins were written by
the Gradle team and those plugins were used to create configuration
files for the specific IDEs (like .idea directory and the .project for
Eclipse). NetBeans did not need those plugins defined (maybe it's true
for IDEA and Eclipse by now).
The only time that concept was violated is the runSingle and explodedWar
task injection. Those are for cover shortcomings of Gradle. In the
meantime Gradle evolved a lot, probably by NB21 or NB22 (more specific
Gradle 8.5+) there would be a standard Gradle way to achieve runSingle
without NetBeans augmenting a build.
It's not about deprecating an API. It's about to encourage people to
take care of their build scripts, in order not to rely on our
heuristics. Also the way IDE actions mapped to build system calls can be
configured in project properties Build > Build Actions
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.
Well, "Run Single" is not supported by Gradle builds, where run, debug
tests and/or test methods are, so we are safe on the test side.
Here you say the users of the IDE are developers. That's not entirely
true, many of them are students, who are often fighting with semicolon
placement problems. For them the injected 'runSingle' task is fine.
I'd say for developers write their own runSingle or extend run task
should not be a problem.
Still, I acknowledge that there are room for improvements. Would that
happen? Maybe. Usual time and money issue (where time is money). I'd
encourage you to step up, if something bugs you, provide a PR, add
documentation, etc. Contribute!
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
