I have converted 30+ projects that were using heavily duplicated build scripts to now using a single binary convention plugin. My guide was pretty much @jendrik's videos and sample projects. Fwiw, it took weeks to grok and get working. YMMV. The result can be found at https://gitlab.com/pajato/gradle-plugins/pajato-convention-plugin which is still a work in progress. Critiques would be most welcome but that is not the point of this post.
One of the included plugins in the master convention plugin is Kover. One configures coverage report filters in the "koverReport" extension such that each project using the pajato-convention-plugin could have a different set of included and excluded classes. That means I would want to put common configuration in the convention build script and specific configuration in the project build script. Only after many more hours did it occur to me that I could have a custom, different "koverReport" extension in each project. This seems to work quite nicely. Would this be considered standard, idiomatic practice? If not, what would be the way to configure multiple, independent projects to use a common set of behaviors and yet still provide individual behaviors for a specific plugin?
👌 1
🚀 3
j
jendrik
06/04/2023, 8:11 AM
Happy to hear that the videos helped! I would say that's exactly the right/idiomatic way to do it. And it reminds me that that's a topic on which I could also do a video simple smile
t
theio
06/04/2023, 8:29 PM
Could you please post some of the sample projects that helped you ? Thanks
p
pajatopmr
06/05/2023, 5:33 AM
Jendrik uses a continuing sample project through his Understanding Gradle series. I also found this NowInAndroid article to be helpful. But far and away the most helpful project was Jendrik's Gradle Plugins Howto where I focused on kotlin-dsl. There are lots more videos and articles that I never got to because those that I mentioned led to my answer.