New JVM Language Plugins

jvm-software-model
plugins

(John Szakmeister) #1

I realize there are several similar topics in the forums already, but most of them seem out-of-date or led to a dead end (the original poster got no responses).

I realize that there’s probably quite a bit of work that goes into a new language plugin, but it looks like there’s been a substantial amount of work done to centralize some key features for other language plugins to leverage. Does anyone know what the state of the union is on that front? Is there new a good example/starting point to being work on a new language plugin?

Also, is there any documentation on the internals as it pertains to new JVM language plugins? I’m mostly interested in seeing a well-supported and well integrated Clojure/ClojureScript plugin. There have been several attempts but they appear to have stalled and are sufficiently out-of-date that they don’t match the current architecture. I’d like to help one of these plugins get rolling again but I’d really like to understand the current model. Any tips, links, or pointers that anyone has to offer would be most useful.

Thanks!


(Andrew Oberstar) #2

I hope you get a response from the devs on this.

My Graclj plugin may be one of those stalled attempts you found. I see a lot of promise in the model-based plugins, but when I last worked on it (over a year ago) it was way too immature to support a 3rd party JVM language plugin. There is some basic documentation in the user guide on creating model-based language plugins, but if you want it to play with the JVM ecosystem you’re stuck reading the source.

I’ve been monitoring the commits on the model subprojects all of 2016, and I’ve yet to see any activity (let alone progress) on this. I’m getting pretty concerned about the future of the model plugins. The user guide used to state that this was the foundation of Gradle 3. In their December newsletter which discussed plans for 2017, the model plugins weren’t mentioned at all. There’s also nothing listed in their GitHub issues about improving the model plugins.

From my perspective, until Gradle more actively communicates and works on the model plugins, they’re a dead end.


(Mike Kobit) #3

I’m on the same page. We have built some plugins around this as it was marked as the “future of Gradle”. Unfortunately, all development seems to have stopped and it has lingered on as an experiment that still exists within the native model, and possibly with Play Framework.

I know there are a few problems with it like:

  • Dynamic Groovy is confusing for users
  • Programming with annotations like this doesn’t give you as much confidence in compile time
  • Testing it is hard and generally seems to require using internals
  • @BinaryTasks and @ComponentBinaries act differently than other model rules and seem to have different binding
  • Binding generic accepting types can be hit or miss sometimes
  • Bridging from current project model is confusing and tedious
  • Hard to leverage existing plugins

But, even with all of these, I found the model to be extremely powerful and was really looking forward to seeing what happened with it. I think the concepts make a lot of sense, but usability and the “the big rewrite” seems to have made writing plugins for the model effectively dead.


(John Szakmeister) #4

Thank you to those who have responded so far–I’m glad I’m not alone in wanting to see this advance and get out there.

Does anyone know if there’s a better way to get the status on things? The Gradle website makes it look like this is the forum for doing so, but it really doesn’t appear to be.

Even if the JVM Language Plugin paradigm isn’t the way to go right now, I’d love to see an outline of the things you need to do/support as a plugin that is compiling code and leveraging Gradle’s features (incremental compilation, etc.). I haven’t been able to turn up much, and what I have seems far out-of-date with the current state-of-the-art.


(Dimitar Dimitrov) #5

Hi John,

As of June 2016, the unofficial stance by the Gradle team was that the model-based API was getting too sophisticated for its own good and may hinder the mass adoption of Gradle. At that time they were taking a step back and evaluating the future direction.

If I understood correctly, one of the options was for the model to be an internal framework underpinning an imperative-looking plugin API; another option was to take the lessons and move on evolving the old-style API. I am not sure what is the current plan.

Regarding best practices on writing plugins, one of the best resources I’ve seen is https://leanpub.com/idiomaticgradle.

There is also https://leanpub.com/idiomaticgradlepluginsvol2 which focuses on the new model-based plugin API, but asn of now it is at 7% (that may be telling in itself)


(John Szakmeister) #6

Thank you. I did find the Idiomatic Gradle book but it only covers through Gradle 2.12. Gradle 3.0 and above introduce a lot of changes, so I wasn’t sure how much of it actually applies. I saw the second book as well, but was saddened that it was not further along.

I guess that leaves me confused about the way forward. Is there somewhere to go that we can learn about supporting incremental compilation, and other such features as part of being a language plugin? Is there a better way of feeding back the desire to have this information to the Gradle developers? I like much of what Gradle offers, but am finding it hard to penetrate to support another language.


(Eric Wendelin) #7

We are deprecating support for the rule engine (and thus the new software-model-based JVM plugins), though we will not remove this until at least Gradle 6.0.

Info and a rough roadmap here: https://blog.gradle.org/state-and-future-of-the-gradle-software-model

Please let Ben or I know if we can clarify anything further for you.