+1 for removing CoS. I think we need to use build tool as it is. If they offer some build optimalization (gradle or mvnd) we can use it but if not then IDE should not do its own "magic" to do things better. Or it could if we would be 100% sure that everything was correct. But I have had lot of problem with CoS especially during surefire tests so I don't think it is this case.
best regards Jakub On Fri, Aug 16, 2024 at 5:30 AM Michael Bien <mbie...@gmail.com> wrote: > > On 15.08.24 18:16, Eirik Bakke wrote: > >> 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. > > Downvote on that. For myself, Compile-on-Save in NetBeans has worked very > > well for for over a decade, and it saves a _lot_ of build time for my > > rather large Maven project. > > Hi Eirik, > > before sending the mail, I spent ~30mins with a hello world program > consisting of 2 classes and a while loop trying to get code hotswap to > work while iCoS is active until I lost patience. > > After switching it off (which is the default these days) it worked on > first attempt. > > > However, the big picture is if we want NetBeans to build projects or if > we want build tools to build projects. To me the answer is pretty obvious ;) > > So this is more about the direction of dev efforts (like a vision > document regarding build tools), and less about an immediate plan of > removing features like invasive-CoS. > > Keeping iCoS around forever, without anyone looking at it and fixing > things would be a mistake though IMO. > > > best regards, > > michael > > > > > > For me, the fact that Compile-on-Save (and Apply Code Changes) works as > > well as it does is one of the main selling points of the NetBeans IDE, > > whenever I consider if I should be switching to IntelliJ. > > > > It’s true that both Compile-on-Save and Apply Code Changes will fail to > > work in certain situations, but I’d rather do a maven build or application > > restart in _those particular situations_, rather than having to do it every > > time. > > > > -- Eirik > > > > From: Michael Bien <mbie...@gmail.com> > > Reply-To: "dev@netbeans.apache.org" <dev@netbeans.apache.org> > > Date: Wednesday, August 14, 2024 at 5:31 PM > > To: "dev@netbeans.apache.org" <dev@netbeans.apache.org> > > Subject: [DISCUSS] Projects, Builds and IDE magic > > > > 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<mailto:dev-unsubscr...@netbeans.apache.org> > > For additional commands, e-mail: > > dev-h...@netbeans.apache.org<mailto: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 > > > --------------------------------------------------------------------- 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
