Clarification on the Gradle model

Help/Discuss
,
1

Hello,

I’ve been looking into using Gradle for projects written in C. From what I can see, it used to be done using the c plugin and the model{} block. I thought that the model was meant to be modified using Rule based model configuration but I see that In the latest version of Gradle there is a note saying:

Rule based configuration will be deprecated. New plugins should not use this concept.

So just to clarify, will the model{} block entirely disappear or will it be configured using another way? I was writing a plugin that is based on configuration via rules (I obviously have stopped now), I guess what I would like to know is: what is now the right way to write a plugin? Are we going back to extensions, conventions and project.afterEvaluate{}?

Thanks in advance

2

I think this is a good place to start:

3

Hi Staffan,

Thanks for your reply. I looked at that article before I posted my question here and I think it doesn’t answer my question completely. I’m looking for information about best practices for writing 3rd party plugins. When rule based model configuration was presented, one of the key points was that it would make sure that objects were fully “realized” at the time you use them, manage mutability/immutability
of objects and that it would somehow prevent third party plugins from stepping on each others’ toes. So just to clarify my question: I would like to know what it the preferred way of writing a 3rd party plugin, and which aspects of the rule based model configuration were kept.

Thanks in advance

4

Lazy properties and providers are also now available.
https://docs.gradle.org/current/userguide/lazy_configuration.html

5

Hi @Chris_Dore ,

Thanks for your reply. I’ve read the documentation, from what I see this can be applied for tasks that you write from scratch. Is there a way to achieve that using existing tasks? I’ll give a quick example to clarify:

Your project generates some arbitrary jars (one containing some java classes, another one containing resources, etc…). In order to do that you just create some new jar tasks and configure them accordingly. But AFAIK the Jar task doesn’t use these properties/providers API, so how would that work in this case?

Thanks in advance.

6

It doesn’t, unless/until the Jar task is updated or replaced.

7

@fredc Ok that’s clear, it’s not the answer I was hoping for but now I know. Do you think extending the Jar task, declaring a new output for that task using the Provider API and wire that output to the normal task output might do the trick? I guess I will give it a try when time allows.