This message was deleted.

I could also copy and paste all the 15 configuration parameters as inputs for my gradle task, but I’m not sure if that makes the readability and maintainability better

Would the Nested annotation work for you?

Even if it works (not sure whether it does here), it would at least be less idiomatic and decrease reusability. With the idiomatic way where the extension and the task do not know anything of each other and the plugin wires their properties together and sets default value, the task is unopinionated and can easily be reused / have additional instances created. Also with having the single properties, you can do things like using the extension to define the values for all tasks, but have it overwritten for specific tasks.

and the plugin wires their properties together and sets default value

What's the idiomatic way to set the default value for the fields of the task? Constructor, setters, property

convention

?

Calling

convention

from within the plugin. The idiomatic way is that the extensions and tasks are as unopinionated as possible and the plugin registers extensions and tasks and adds opinion to them in form of wiring extensions and tasks together and setting default values.

Can tasks specify their own defaults, for ease of reuse in build scripts? In other words, if I use the task through a plugin, the plugin should integrate the task with the extension; but if I use the task directly, I shouldn't have to configure all of its properties manually

Of course it can, but it shouldn't. If you want to stay idiomatic.

You explained that it's the coupling between the task and the extension that is objectionable and non-idiomatic. The mere presence of default values for a task's fields should not necessarily create coupling. In fact, the intention here is to make the task easier to reuse by itself, e.g. by creating additional instances

No, I explained that both, extensions and tasks, should be as unopinionated as possible. Any coupling and any default value is opinon. The plugin should add opinion by wiring extension properties with task properties, be registering default tasks, and by setting default values.

I randomly pulled up

JavaExec

and its constructor sets default values exactly as I would expect:

javaExecSpec = objectFactory.newInstance(DefaultJavaExecSpec.class);
        javaExecSpec.getMainClass().convention(
            getMainClass().orElse(
                Providers.changing(
                    // go through 'main' to keep this compatible with existing convention mappings
                    () -> DeprecationLogger.whileDisabled(this::getMain)
                )
            )
        );
        javaExecSpec.getMainModule().convention(mainModule);
        javaExecSpec.getModularity().getInferModulePath().convention(modularity.getInferModulePath());

The reason this makes sense to me is because it appears to be idiomatic for build scripts to register/create a given task class pretty much directly, not by invoking some plugin-provided factory method that sets defaults

Noone said, that the Gradle source is fully idiomatic. 🙂

But that raises the question of what should be done, both by plugin/task developers and by users

Well, you asked how to do it idiomatically and I told you. What you make out of this information is up to you. You can also have multiple plugins, for example one that applies these defaults to all tasks of that type if a user wants that behaviour. Or you can provide a utility method in some extension to set the defaults. Or you can make it unidiomatic and have the defaults within the task.