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