Support for multiple NetBeans Gradle Tooling

[lkishalmi]

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.

[sdedic]

A suggestion: if a GradlePluginProvider had a method boolean accepts(GradleRuntime r), then the providers can be filtered centrally. In the current state, each of the methods (classpath, plugins) need to accept GradleRuntime and test for applicable version.
Alternatively (future-compatible), suggest to have just

@CheckForNull GradlePluginDescriptor getPlugins(GradleRuntime r);

public final class GradlePluginDescriptor {
    Collection<File> getClasspath(GradleRuntime runtime) {...}
    Collection<String> getPlugins(GradleRuntime runtime) {...}
}

which could eventually allow to compatibly add more information in the future, if needed.

[sdedic]

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

[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.

[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.

Definitely.

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

[lkishalmi]

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.