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
