> 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
