On 16.08.24 11:19, Jan Lahoda wrote:
Hi,
Hi Jan!
First, I would like to take a step back and ask what's the purpose of an
IDE. I think the purpose is to help developers to write better applications
faster and more conveniently. If some more "magic" helps with that goal, it
is not bad, I think.
NetBeans specifically was "always" very close to the underlying build
systems - building/running/testing a project is (except for some CoS modes)
done by running the underlying build system. This was "always" a strong and
weak point for NetBeans - strong because there's a high fidelity between
the IDE and any command line/CI build. Weak because the CI builds tend to
be pretty slow, and generally don't give that much thought about IDEs,
being meant primarily for CI.
But, even for NetBeans , there is some level of extra-build system magic,
as the IDE runs the build system with a specific setup and interprets the
results. For example, if I run a single test method under a debugger, the
IDE will compose a Maven command line for me, start a debugger, and let the
JVM running the test connect to the debugger. And when the test run ends,
the Test Results will show me whether the test succeeded or not. I surely
would not want to compose the command line manually, attach to a remote
debugger and interpret the results myself.
So, I don't think some level of magic is bad. The discussion, I guess, is
what level of magic is the right one.
I fully agree. The example you give here is actually great since it
links directly to example 1 of the original mail.
The run-single-test-method action is directly mapped to the equivalent
maven goal (with some extra -D properties), the build tool (maven) does
the rest. This is how it should be IMO. (good magic)
A brittle implementation here would be to assemble the "java -cp ..."
command line and run the test case. This is the wrong kind of magic - it
solves an already solved problem again just within NB.
Delegation allows here to fix the windows process args length limit
issue by simply guiding the user to set -Dexec.longClasspath=true or
adding <longClasspath>true</longClasspath> to the project pom and the
build is fixed for the windows platform. If NB would not call a maven
goal here, the same workaround would have to be implemented within NB.
This changes https://github.com/apache/netbeans/issues/7582 from a bug
into a feature request. All what is needed is a more descriptive error
message. (best place for this might be even in the maven exec plugin itself)
More specifically on the two things mentioned:
"Priming" builds
----------------
What we (I think) need is a way to ensure the project's dependencies are
ready/downloaded, as without those, many things are broken. And I don't
think we can leave this completely up to the user to figure it out. I.e.
what I think we need is a) a warning/warnings to the user that some kind of
dependency download is needed for the IDE to work well; b) an easy way for
the user to trigger the download, and verify success (similarly to an easy
way to run a single test method under a debugger).
Right, the important thing here is that again: maven itself is used to
download the dependencies. This ensures that they land in the right
place. The project/maven setting knows how to handle maven 4 split repos
for example - NB doesn't right now.
By delegating this to maven again, it increases the probability for NB
to be forward compatible with future maven versions, without having to
fix the impl within NB.
Regarding how UX could look:
NB can't load the project, notification shows up giving the user the
option to
a) build the project right away (this is often one of the first
things you want to do anyway)
b) run
https://maven.apache.org/plugins/maven-dependency-plugin/go-offline-mojo.html
(or something similar)
c) run some custom plugin which downloads a subset of the required
dependencies if there is the need for such thing (I hope not)
what if the user would not want to do any of this? (offline in a train?)
As last resort:
a) NB could simply open the project anyway since maven projects have
well known structure (errors will show up in editor)
b) NB can also open arbitrary folders as view (try dropping a folder
into the editor - might not work with all launchers)
Whether the action to resolve the project's dependencies is just running a
Maven target and interpreting the result, or something more fancy and/or
direct is, I think, mostly a question of what works most reliably. (We
could even have our own Maven plugin doing the download if that would be
what would work best. I don't see a conceptual difference between "mvn
download:go-offline" and something like "mvn
org.apache.netbeans.maven:download:download-dependencies").
Well, the difference is that we would have to maintain the netbeans
specific plugin, the other plugin is already there and maintained by
apache maven devs ;)
Even if we would have specific requirements or requests, we could also
try to get them into the "official" maven plugin.
CoS
---
I am not a huge fan of CoS, but:
The CoS had two main purposes: a) make the builds faster; b) permit running
erroneous/uncompilable code (throwing an exception at the point of error).
Both of these were to shorten the edit-compile-debug cycle.
And while I believe the length of the cycle was improved in many cases when
using plain build system build, I would be surprised if there weren't cases
when the Maven build is still slow, and CoS works for them.
So, I think it is right for CoS to be disabled by default, but as long as
we can keep it working, and as long as people are willing to accept any
limitations of it to speed up their edit-compile-debug cycle, I don't see
too much of a problem with that.
I don't want to push for a immediate removal of invasive-CoS. But in its
current state it should be probably deprecated and the UI needs to do a
a better job at explaining what side effects are.
It has too many bugs right now unfortunately, causing problems in areas
which are not directly connected to the feature from the user's
perspective (e.g https://github.com/IQSS/dataverse/issues/10728).
CoS was actually originally not even something I wanted to bring up in
the mail, but It is better to talk about things like this ahead of time,
otherwise we can get into a situation where a feature has to be removed
under time pressure since it breaks something while nobody wants to
touch it anymore.
https://lists.apache.org/thread/xh9r5kyt404qx0dtygnkytlrr7c9g0or
https://github.com/apache/netbeans/pull/7542
(We could also consider disabling CoS by default also for the Ant projects.)
yep!
thanks a lot for participating in the discussion!
best regards
michael
Thanks,
Jan
On Wed, Aug 14, 2024 at 11:31 PM Michael Bien <mbie...@gmail.com> wrote:
Hello devs,
i would like to bring up a topic which came up a few times during PR
discussions or on slack, but I don't think it landed on the mailing list
yet. Originally I wanted to wait with it for the the quiet time between
releases, but since this topic came up again recently I thought - why
not now.
In my opinion, IDEs should keep the build-time magic at a minimum, in
fact I think a good way of thinking about this is:
- if the build fails in CLI, it should also fail in your IDE
What does this mean? Lets go right to examples:
example 1:
Windows has process arg-length limitations (additional to the better
known filepath limitations). But all build tools added workarounds for
this by now. So instead of adding magic to the IDE to workaround long
classpath arguments too, a much better approach would be to detect the
situation and tell the user that the build is broken. Since often all
the user would have to do is to add
'<longClasspath>true</longClasspath>' to the right plugin. (#7582, ...)
example 2:
Build tools itself can have bugs where the best and easiest solution is
to simply update the build tool to the next point release. (#7558, ...)
Older versions of the maven wrapper for example had a bug which broke
execution when certain file paths were used. Instead of adding a
workaround for this in NB (which would have to be maintained forever and
could itself cause problems), all NB could do is to notify the user and
then run 'maven wrapper:wrapper' once - thats it! IDEs should not
magically work with a build even if the build would fail in CI when run
in the same environment.
Both examples above are situations which would fail in CLI and should
also fail in the IDE. The IDEs job there would be to give hints to the
user how to get out of the situation. in short: IDE workarounds would
become user facing hints where possible with the goal to improve the
project instead of hiding issues.
But there is more, even darker, magic: iCoS and priming
NB has a feature called "compile on save". Since this feature is fairly
invasive and was implemented side by side to "on save" and
JVM-code-reload actions, I am going to apply some apple branding here
and call it i(nvasive)CoS to distinguish it from other functionality
which might run on-save.
iCoS might have made sense back when build tools were fairly limited (no
mvnd, incremental builds, small plugin ecosystem etc) and workstations
had different hardware realities (mechanical disks, no noteworthy
memory). It attempts to speed up certain actions by completely ignoring
the build of the project and compiling code directly into the target
folder (!). I think this should have been hard to sell even back when
the speedups were significant ;)
Today iCoS is essentially broken (doesn't work during debugging, breaks
many non-trivial projects, causes other functionality to fail e.g
running tests)[1,2]. If there would be still the need for something like
iCoS today, it would be implemented in the build tool, not in IDEs.
Lets agree to phase out iCoS and remove it at some point. Some of its
functionality can be directly mapped to "on save" actions, e.g "Apply
Code Changes"-on-save during debugging which currently doesn't even have
a hotkey.
project priming:
Many features require build dependencies, like maven plugins or project
dependencies, to be available first, before NB can make sense of the
project. This lead to more magic during project load. If you open a
maven project in NB and don't have a ~/.m2/ folder yet, you will notice
that it automatically downloads and installs plugins and dependencies.
(interestingly, this doesn't happen every time, sometimes it will ask
before running a priming build, during cluster activation it doesn't
seem to ask - which is interesting)
This is currently also likely the reason why NetBeans doesn't support
maven 4 split-repos (#6190). Proposal: ask user to run 'maven
dependency:go-offline' or offer to skip it and build/run the project
right away. I personally never go through the "resolve dependency issue"
dialogs or priming notifications, I simply press build. If there would
be a "download build dependencies" action (or notification), i might
press that sometimes instead.
in summary, this would hopefully:
- be more transparent for the user by removing some of the magic
- improve projects (help to improve the build; no "works in my IDE,
lets deploy my IDE" scenarios)
- make maintenance easier (less workarounds, better chances to be
forward compatible, see mvn 4 split-repos)
let build tools do the work instead of reinventing the wheel inside the
IDE (and let us finally remove iCoS :))
best regards,
michael
refs
[1] see scary warning dialog if you enable iCoS
[2] https://github.com/IQSS/dataverse/issues/10728
#7582 https://github.com/apache/netbeans/issues/7582
#7558 https://github.com/apache/netbeans/pull/7558
#6190 https://github.com/apache/netbeans/issues/6190
#7655 https://github.com/apache/netbeans/pull/7655
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-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: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
