Hi,
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.
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).
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").
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.
(We could also consider disabling CoS by default also for the Ant projects.)
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
>
>
>
>
