Internal APIs in new model JVM language implementations

I am looking at what is required to add a new JVM language using the new model. Firstly I am going to apologise if can case parts might came across as negative criticism. That is not the idea. I am fully aware that the model is still incubating and evolving. I also know that some plugin authors are already experimenting moving their JVM language plugins to the new model (Gosu sptings to mind). I actually hope that my questions will rather flush out shortcomings which can be addressed:

For the rest of this let’s just assume that a language called Foo will be added.

FooLanguageSourceSet:
I have posted a question related to this in the gradle-dev ML, but it is worth noting here. FooLanguageSourceSet can be created easily by extending BaseLanguageSourceSet, yet the docs state that an implementation class should not be ysed rather just annotation with @Managed. This is confusing as both the Java- & ScalaLanguageSourceSet implementations do not follow that advice.

FooRules:
Working off the inner class in ScalaLanguagePlugin, a number of things spring to mind.

  • The use of ServiceRegistry which is an internal API. I would have hoped that with the new model we could get away from those damn internal APIs for language implementation. If there is an alternative that can be used that is public then it would be good to know. Otherwise making it public would be the next option.
  • LanguageTransformContainer & LanguageTransform are two other internal APIs, that are being used to create and register the language class. Same kind of arguments as before apply here.