Hello Laszlo. I acknowledge and see the added value by the VS Code movement. >
To get the most from the "movement", it'd be ideal to find synergy between the "movement" and regular NetBeans IDE. By introducing ... > I do not think that having an LSP Gradle module for customizing actions > would mean a "fork". > ...new module we are duplicating the amount of work and reducing the synergy. If we go that path, then it may happen that some features are going to be available only in VSNetBeans. I would find that unfortunate. Right now VSNetBeans offers code lenses for "Run/Debug method" - https://github.com/apache/netbeans/pull/2705 - a functionality which isn't present in regular NetBeans. I'd like to minimize such deviancies rather than encourage them. Ideally the `java/java.lsp.server` and its `vscode` extension are just a thin UI wrapper around general functionality of NetBeans. > It'd mean that LSP has another way to customizing execution. Which seems > to be true. So a bridging module would be Ok. > True, there is a different UI in VSNetBeans to customize execution. However there is nothing VSCode/LSP specific on that. The `java/java.lsp.server` is just reusing the well established https://bits.netbeans.org/12.0/javadoc/org-netbeans-modules-extexecution/org/netbeans/api/extexecution/startup/StartupExtender.html requested by tools like JRebel & co. in the past. The startup extender is an API implemented by Ant projects, Maven projects. By using it in VSNetBeans we contribute to the unification as well as [improve it to also support user arguments](https://github.com/apache/netbeans/pull/2731). > However if you find the current NB Gradle API too weak, It would be great if this startup extender and the `ExplicitProcessParameters` were also supported by Gradle projects. At least my assumption (when approving #2731) was that it would happen eventually. > I just would like to avoid to have an action customization SPI, and > another SPI to infiltrate more Gradle Options into the command line. > The assumption of JRebel guys was (and they managed to convince me about that): it doesn't matter what project type the IDE is using, but there should be a unified way to influence the execution arguments. Only then we can have simple integration with tools like JRebel (or [native-image agent]( https://www.graalvm.org/reference-manual/native-image/BuildConfiguration/)). We want such tools to treat project as an opaque thing and integrate with all of them at once via abstractions like `StartupExtender` without need to create NxM integration matrix (N being number of project types and M number of tools) of bridge modules (old approach used by profiler, for example). > However if there is a strong reason that supports the need, I can be > convinced. > I perceive the ideal of `java/java.lsp.server` + vscode extension being just a thin UI wrapper around generic NetBeans concepts as a very strong reason. I hope such vision help you get convinced. -jt > On 3/9/21 1:55 AM, Jaroslav Tulach wrote: > >> So at worst, a supposed "LSP Gradle" module would provide a > >>> replacement for project run, debug, profile actions + suck (somehow) > >>> the rest of actions from standard Gradle support ? > > That's what I've meant, and yes fallback to the existing implementation > >> needs some love in the code to be possible. > >> > > Hello Laszlo, > > when the Apache NetBeans Language Server Extension effort started, one of > > the common worries was: isn't that forking NetBeans? > > > > It is a valid worry, but I believe that so it has been demonstrated that > > our effort to provide a VSCode extension can help NetBeans overall. The > set > > of contributions to NetBeans 12.2, which wouldn't be possible otherwise, > > speaks for itself: > > > > > > https://github.com/apache/netbeans/pull/2471 > >> https://github.com/apache/netbeans/pull/2464 > >> https://github.com/apache/netbeans/pull/2427 > >> https://github.com/apache/netbeans/pull/2393 > >> https://github.com/apache/netbeans/pull/2309 > >> > >> https://github.com/apache/netbeans/pull/2523 > >> https://github.com/apache/netbeans/pull/2424 > >> https://github.com/apache/netbeans/pull/2407 > >> https://github.com/apache/netbeans/pull/2396 > >> https://github.com/apache/netbeans/pull/2390 > >> https://github.com/apache/netbeans/pull/2360 > >> https://github.com/apache/netbeans/pull/2358 > >> > >> https://github.com/apache/netbeans/pull/2481 > >> https://github.com/apache/netbeans/pull/2474 > >> https://github.com/apache/netbeans/pull/2467 > >> https://github.com/apache/netbeans/pull/2452 > >> https://github.com/apache/netbeans/pull/2436 > >> https://github.com/apache/netbeans/pull/2429 > >> > >> > > Overall I am trying to argue in favor of sharing as much as possible > > between VSNetBeans and regular NetBeans IDE. As such I am worried about > the > > need for special "LSP Gradle" module > > > > a supposed "LSP Gradle" module would provide a > >> replacement for project run, debug, profile actions > >> > > that would just contribute to "forking" the code base. I'd like to avoid > > such module and rather come up with good enough abstractions in the base > > implementation. > > -jt > > > > --------------------------------------------------------------------- > 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 > > > >
