On Thu, 15 Aug 2024 at 17:18, Eirik Bakke <eba...@ultorg.com.invalid> 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.
I'm with Michael on this. I'd like to see invasive-CoS (nice name!) killed with fire, as I've said numerous times. I've been the exact opposite, religiously turning it off on every project for well over a decade. One NetBeans' ethos has been to be a UI to the build system, and it's one I completely agree with. I think our time would be better spent looking at default configurations, etc. to make better use of the build tools themselves, towards a state where people don't feel that CoS offers additional value. At the same time, some people will want to keep using CoS, at least as long as it remains functional (I'm not quite sure how long that will be). I've thought for a while we could possibly make use of a single legacy features switch, that's off by default, to hide some things from the default UI. > From: Michael Bien <mbie...@gmail.com> > - if the build fails in CLI, it should also fail in your 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. +1 > > But there is more, even darker, magic: iCoS and priming ... > 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 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'm in agreement here. The whole priming, and currently in discussion project reload API, would ideally be centred around direct use of the build tools, and explicit control from the user. In particular where such tasks require executing things such as Maven wrapper. We should probably enhance the idea of project trust, which is currently on/off. If certain tasks, say editing a POM, are going to require execution of the build tool, then I'm happy for a UI option that enables auto-running that task for that project, as long as the user has given informed consent. I'm curious how much our embedded Maven is going to cause problems as we try and support v3 and v4 simultaneously. It would be great IMO if we ever got to a stage where we didn't ship with Maven at all (like Gradle), but a lightweight library and Maven wrapper - a Maven Tooling API?? I guess that's .. unlikely at the moment! > - be more transparent for the user by removing some of the magic ... > let build tools do the work instead of reinventing the wheel inside the > IDE (and let us finally remove iCoS :)) Wholeheartedly +1. Best wishes, Neil --------------------------------------------------------------------- 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
