On Fri, 16 Aug 2024 at 10:19, Jan Lahoda <[email protected]> wrote: > 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.
Thanks, Jan. This! I think we're all in agreement that this is what the IDE *should* be doing? Perhaps we need to be clearer on the definition of "magic"? Composing the Maven command line then interpreting the results in the easiest and most useful way is exactly what the IDE should be doing. Bypassing the Maven command line part of that in the process is perhaps the kind of "magic" we're talking about here? > "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. The UI part of this, as far as I'm concerned, is also exactly what the IDE should be doing (and isn't in all cases). The question between running a Maven target and something more "direct" is perhaps where the conversation about magic comes in? At least if we're talking about calling directly into the embedded Maven libraries. We should be using the Maven version the project itself is using, and this may become more of a concern as we try to support differences between Maven 3 & 4? > 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. But is the answer CoS, or the use of local Gradle and Maven daemons, etc? > So, I think it is right for CoS to be disabled by default, but as long as > we can keep it working, For at least some scenarios, as Michael mentioned earlier, that may not be keep it working, but get it working again?! Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
