netbeans Support for multiple NetBeans Gradle Tooling

This one is a proposed draft to allow plugins to provide their own discovery tooling library.

The motivation is that right now every Gradle discovery has to go into netbeans-gradle-tooling external library,Which is already stuffed. Also to be future proof we probably would use different version of these libraries when working with different Gradle versions. Right now we are using Gradle 7.4 to build our tooling on, which still has support for deprecated APIs, but already has new enough recent features. That might be no longer true with Gradle 9.0.

This would be a multi commit series PR. The first one is extending NetBeans with a GradlePluginProvider service. The following would be figuring out how to wire this support into the project introspection.

Dec 11 '23 07:12 lkishalmi

A question: I couldn't find a roadmap / tentative schedule for Gradle 9.0 ... can you share a link?

Dec 11 '23 07:12 sdedic

There is not too much info on Gradle 9.0, besides a bunch of warnings, that things are up for a removal.

So I do not know for sure if Gradle 9.0 would break anything. I think you would agree that the tooling code is already "stretched" enough with beforeGradle() and afretGradle() phases.

Dec 11 '23 16:12 lkishalmi

There is not too much info on Gradle 9.0, besides a bunch of warnings, that things are up for a removal.

So I do not know for sure if Gradle 9.0 would break anything. I think you would agree that the tooling code is already "stretched" enough with beforeGradle() and afretGradle() phases.

Definitely.

Do you plan also to make the Extractors to be version-aware ?

Dec 11 '23 16:12 sdedic

Do you plan also to make the Extractors to be version-aware ?

Good point. Shall we? I'm thinking of that they are providing an ugly but stable serialization facade to NetBeans. If it is not necessary I would don't go into that direction.

The primary goal here is to provide plugins to have their own tooling. I'd like to have one that provides ANTLR source sets on the project UI. with the current structure, I'd need to add that as a GradleJavaSourceSet.SourceType which oddly fits there and I would like to avoid that.

Dec 11 '23 18:12 lkishalmi