From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

As I never heared of `packagingOptions` or `pickFirst` I guess that's something <#CJYS1DAP5|> specific and you might be better asking there.

Do you need jetifier? Looking at the release notes of AGP 7.2, the preference is to try and move off of using it now.

```tasks {
    named&lt;Copy&gt;("backendProcessResources") {
        val webpackTask = getByName&lt;KotlinWebpack&gt;(if (isDevelopment) "frontendBrowserDevelopmentWebpack" else "frontendBrowserProductionWebpack")
        val jsMinifyTask = getByName("jsMinify")
        val cssMinifyTask = getByName("cssMinify")

        exclude(
            // These files are preprocessed by the minify plugin, exclude them from the copy task
            "static/js/**",
            "static/css/**",
        )

        into("WEB-INF/") {
            // TODO: Does not work, instead places into /templates as if this doesn't exist
            into("templates/") {
                from("templates/")
            }

            into("static/") {
                into("js/") {
                    from(webpackTask.destinationDirectory)
                    from(jsMinifyTask) {
                        rename("(.*)\\.min\\.js", "$1.js")
                    }
                }
                into("css/") {
                    from(compileSass)
                    from(cssMinifyTask) {
                        rename("(.*)\\.min\\.css", "$1.css")
                    }
                }

                // TODO: Does not work, instead places into /static/img as if this doesn't exist
                into("img/") {
                    from("static/img/**")
                }
            }
        }
    }
}```

`into` returns `this`, so there's no such thing as nested `into` statements, they're all calling the same `rootSpec.into`

(this being the AbstractCopyTask instance)

That's odd, because it does work for the js/css files. While it does return `this`, doesn't it create a new copy spec for the nested block's context receiver? From the javadoc:
```Creates and configures a child CopySpec with the given destination path. The destination is evaluated as per org.gradle.api.Project.file(Object).```
But the main problem is that it doesn't seem to find the img and template folders, any clue what could be the issue there?

ah, interesting, I might've misinterpreted that api indeed :slightly_smiling_face:

have you tried flipping the `from` and `into`? I've always found that to be more intuitive to reason about. I'm not sure how the copyspec closure interprets those relative paths in such a setup.

```        into("WEB-INF/") {
            from("templates/") {
                into("atemplates/")  // different name to see if maybe it adds to root?
            }```
The files are still put into /templates, no change in behavior here.

while flipping the order can be more intuitive, having it as tree structure make the code a lot more clean imo

I mean, at the root. Treat individual `from` sources as separate copyspecs, instead of organising by target :thinking_face:

but that said. If you change `from("templates")` to `from(layout.projectDirectory.dir("templates")`, does that fix it?

```        from("templates") {
            into("WEB-INF/templates")
        }```
also did not work

&gt;  but that said. If you change `from("templates")` to `from(layout.projectDirectory.dir("templates")`, does that fix it?
Wouldn't that try to target the `templates` folder as if it were in the project root rather than from the resources root?

isn't that what you want? the first `into` isn't referencing the webpack task anywhere, right?

No, it should be relevant to the current task shouldn't it? this is the processResources task, not the webpack task

Here's a visual aid; Yellow is handled by the webpack task and the sass task, red is handled by the minifier, and orange is what I'm trying to copy into specific folders

what is the end artifact you are producing?

what do you mean? The end artifact is just a jar that'll run the website

are you getting anything inside the WEB-INF folder? because I can't get anything to show up there, using the processResources task :thinking_face:

The js and css files from the other tasks show up just fine

Also, I'm pretty sure your `from` closures aren't working as you expect they should. You're just seeing those files coming from inside the resources folder in the output, because that's the default configuration of the task: <https://github.com/gradle/gradle/blob/master/subprojects/plugins/src/main/java/org/gradle/api/plugins/JavaBasePlugin.java#L191-L192>

So how would I approach something like this

```2022-09-14T16:35:57.108+0200 [INFO] [org.gradle.api.internal.file.collections.DirectoryFileTree] file or directory '/test/templates', not found
2022-09-14T16:35:57.109+0200 [INFO] [org.gradle.api.internal.file.collections.DirectoryFileTree] file or directory '/test/static/img/**', not found```


you have to make sure you point to the correct location in your from statements. if I change one to `from("src/main/resources/templates")`, it just works

but you do get duplicate files in your jar file, as these resources are copied twice

hmm, so there's no way to do it without hardcoding the resources path?

I would probably store these files somewhere else. You don't want them to be in the default location for resources, so set up a separate folder instead. Whether you want to leverage the processResources task to copy them, or configure a separate task is up to you.

So you're saying I should put my resources in a not-resources folder? Why? I'm just trying to relocate most of them to a separate directory

the problem is that they will be in 2 locations, right? both the default location, because of the default configuration of that task, as well as the "WEB-INF" location, once you correctly specify the `from`.

yeah, but even just getting it to place all files in WEB-INF isn't working as `into("WEB-INF")` makes it put the WEB-INF folder relative to the project root instead of the build/resources/... folder

~you can't use the nested into approach if you want to affect the root copy spec (which is the one that's setup with build/resources as output root)~
hold on, that might not be correct, I'm not sure how the rootspec and mainspec in the AbstractCopyTask interact :thinking_face:

It looks like the two are completely independent, which confuses me even more

I think for your own sanity, it's safer to consider those resources as an independent resource. In the jar, there's no resources folder anyway, so it doesn't matter for your end result.

But then how do I get intellij to still treat it as a resource root?

you can mark it as such using the idea plugin

```idea {
    module {
        resourceDirs.add(file("your_folder"))
    }
}```


Never use extra properties, they are almost always just a work-around. Register a new extension with a `DirectoryProperty`. Wire that property to where you need it. Then the customers can configure that extension and you even get implicit task dependencies as needed.
If the target for that folder is not yet in lazy API, but needs `File` or similar, you can for example make the extension not have a property but a function to which you give the directory and in the body you do the according configuration.

:thinking_face:  Hmmm, so it is possible to register extensions on precompiled script plugins? I thought that was something for full fledged plugins only. How do you link the extension to the script plugin? And how to write the extension? You have to do that with a separate Kotlin or gradle class, or is there a more “scripty” way to do it. Do you place the extension right next to the .gradle.kts file in buildSrc?

Tnx for the help by the way Vampire, you helped me out in the past already with other questions. Impressive that you keep helping people in the chat. :thumbsup:

Of course it is. Anything you can do in a regular plugin you should be able to do in a precompiled script plugin. They are more or less just syntactic sugar for writing a plugin with little boilerplate.

Not sure what you mean with "link".

Regarding how to write you are flexible. You can write it in a separate .kt file like a normal class or interface. Where you place it follows the same rules as any other Kotlin code, you can basically put it anywhere or put it in a directory structure according to packages you set.

But iirc you can also just declare the interface for the extension inline in the script. I don't have a computer with me, so cannot try, but I think it should work just fine.

Offhand, what comes to mind is to check if `ignoreFailures` is set to true on the test task?  Or force it to false?  Maybe run with --info to see if there is more logs about it.

I am not changing the value of `ignoreFailures`

Maybe something else is.  As part of debugging and eliminating possibilities, you can print the value of it to confirm.

are you using the <https://plugins.gradle.org/plugin/org.gradle.test-retry|test-retry> plugin? if so, that behavior is intentional

<@U019L3NM4PK> yes, I am using it in that project

can you see if your gradle scripts have an import for that accessor?

Hi Christian.  I'm not sure exactly what you means.  Do you mean theh actual java/kotlin import in the build scripts or like in the plugins block id("convention-file") ?

I do have some gradle build scripts (convention files) that import from an included plugin, yah.

All those issues have been closed by stale bot already. I am only changing the reason for closing from completed to not planned.

I am sorry about all the noise :disappointed:

If anybody has and idea how to use the Github rest API without causing the notification I’d be happy to do those things differently.

I'm wondering whether really all of these were closed by the stale bot for good. For example at <https://github.com/gradle/gradle/issues/16596#issuecomment-1159096408> I at least tried to reopen the issue / remove the "stale" label, but I guess that did not work. Anyway, I believe that issue should stay open, as it's closely related to an open roadmap issue.

Also at <https://github.com/gradle/gradle/issues/11065#issuecomment-747677878> it was tried to get rod of the stale bot, and it also did not work.

So maybe only close them as "not planned" if there was not comment after the stale bot's one?

And we are even working on the first one.

Regarding the stale bot things: The comment to keep something alive only helps if it comes before stale bot (or now stale action) closes the issue. After that is done, an actual Gradle engineer needs to reopen the issue. It seems like that didn’t work for the two issues mentioned above.

I've seen multiple other issues closed by stalebot even when I've commented *before* the bot closes the issue

I’d still not keep them closed as completed, given that they definitely have not been completed.

is there something wrong with the stalebot configuration?

&gt; I’ve seen multiple other issues closed by stalebot even when I’ve commented *before* the bot closes the issue
Stale bot had some bugs, and now we moved to the stale action that may be more reliable. You can find the configuration here: <https://github.com/gradle/gradle/blob/master/.github/workflows/stale-issue.yml>

It really should be removed entirely and issues should be kept open until a human can prove that it is invalid, not needed anymore, duplicate, … instead of blindly closing issues. At <https://github.com/rust-lang/rust/issues> they have 5k+ issues and do not resort to these kind of community disgrunting measures.

<https://gradle-community.slack.com/archives/CA7UM03V3/p1663344502483719>

in my `BuildServce` - I need to invoke a CLI command

constructor or property injection instead of params, same goes for all of these types: <https://docs.gradle.org/current/userguide/custom_gradle_types.html#services_for_injection>
```abstract class MyBuildService @Inject constructor(
    private val execOperations: ExecOperations,
) : BuildService&lt;MyBuildService.Params&gt;

// or this
@get:Inject
protected abstract val execOperations: ExecOperations```

any idea why I can’t inject a `Logger` into a `BuildService`?

`DefaultTask` has a `Logger` - but AFAIK there is not one for `BuildService`.

Thanks!

project, script, and task instances have a getLogger() method. but it's not a service that Gradle knows how to inject in general

<https://github.com/gradle/gradle/issues/16991>

Cradle Devs told me to open an issue for the same reason, but... I didn't think about using Logger.getLogger

In any case..then you don't have the custom Gradle levels, do you?

`Logger.getLogger` returns an `slf4j` type logger, right?

I want a Gradle logger

kinda silly to not being to use the Gradle logger in a `BuildService` lol

As I said, I asked them, they asked for the issue but.. surprise! There is one already and it got closed.

`org.slf4j.Logger` doesn't have Gradle-specific levels, but `org.gradle.api.Logger` does

Gradle's logging is set up such so that the loggers are all Gradle-wrapped either way, but if you use `org.gradle.api.Logger.getLogger()` then you don't have to cast it

Oh, noups, stale but removed the label without any comments :cara_pensativa:

It is sufficient to modify any comment to keep it open. :-)

write a settings plugin, you can get a `BuildEventsListenerRegistry` injected into it

yeah that’s the only way I could figure it out

that is the only supported method for getting it

It isn't, is it?
Make an interface with a field of that type injected, then use `objects.newObject` to create such an instance and get the property.

how do you get an ObjectFactory in settings.gradle?

Oh settings script, sorry.
Only other way would then be to delay it until the root project is realized if that is sufficient using `gradle.rootProject { ... }`

<https://docs.gradle.org/current/userguide/build_services.html>
&gt; A build service implementation can also optionally implement `AutoCloseable`, in which case Gradle will call the build service instance’s `close()` method when it discards the service instance. This happens some time between completion of the last task that uses the build service and the end of the build.

well, almost perfect. I need the exception to know if the build is cancelled, lol

you have access to every failure as it happens,
```private val allFailures = mutableListOf&lt;Failure&gt;()
override fun onFinish(event: FinishEvent) {
    val result = event.result
    if (result is FailureResult) allFailures.addAll(result.failures)```

Prefer `withType&lt;…&gt;().configureEach { …` for true configuration avoidance.
Prefer `destinationDirectory.convention(project.layout.buildDirectory.dir("plugins"))` (== avoid .internal. Gradle classes, and avoid `.get()` when provider properties are available)

And make the properties `val`, not `var`, then they should be set I think.

Using `gradle.taskGraph.whenReady` and throw if it `hasTask("idea")`? (not sure it's compatible with configuration cache though)

Interesting thought, `hasTask(String)` takes an "_absolute path of the task"._ I tried with "idea" and the FQN, but no luck. I'm not sure how to actually invoke the `hasTask(Task)` API as it takes an instance of a task :thinking_face:

I got the intended result through this snippet of code, though it's not very elegant :face_with_rolling_eyes:

```if (idea.module != null) {
  tasks.named("ideaModule") {
    enabled = false
  }
}

if (idea.project != null) {
  setOf("ideaProject", "ideaWorkspace").forEach { taskName -&gt;
    tasks.named(taskName) {
      enabled = false
    }
  }
}

if (idea.project != null) {
  tasks.named("idea") {
    doFirst {
      throw RuntimeException("To import in IntelliJ IDEA, follow the instructions in $ideaInstructionsUri")
    }
  }
}```

This worked for me:
```gradle.taskGraph.whenReady {
    if (hasTask(":idea")) throw RuntimeException("To import in IntelliJ IDEA, follow the instructions in ...")
}```
both in `settings.gradle.kts` or `build.gradle.kts`

Using `hasTask(":idea")` worked for me:

```gradle.taskGraph.whenReady {
  if (hasTask(":idea")) {
    throw RuntimeException("To import in IntelliJ IDEA, follow the instructions in $ideaInstructionsUri")
  }
}```
console output:

```FAILURE: Build failed with an exception.

* What went wrong:
Failed to notify task execution graph listener.
&gt; To import in IntelliJ IDEA, follow the instructions in ...```


Oops, sorry, yes, it has to be `:idea`, not `idea` (bad copy/paste from various tests in snippet above, edited/fixed now)

Thanks for the assist <@UDC9Q9RD0> :raised_hands:

I suppose I now have good reason for a dive into the configuration cache docs :smile:

```capabilities {
	requireCapability("${libs.my.logging.spring.boot.support.get()}")
}```


How simple. Thank you!
Btw, I found no API description of it. Can you please point me the right direction?

`requireCapability` needs a `Capability` or a `String` in the form of `group:name:version`. The accessor directly gives you a provider which I just got and made a `String`, guessing the result and `println` confirmed. :-)

You could try using the `subprojects` block?

Although I’m not  fond of a root level configuration for publishing setups.
 You could create a method at the root project which takes a project and configures its publishing and then call  the method from each of the projects you want to publish?

Alternatively creating something in buildSrc would also work.

Using the `subprojects` block worked, thanks. However, I agree with you on not putting the publish config on the root level. I think I'd go with putting it in buildSrc.

Actually, you should put *nothing* in `allprojects { ... }` or `subprojects { ... }` that's a legacy antipattern.
Instead create convention plugins in an included build or if you prefer `buildSrc` and apply it where you want its effect.

I tend to think that tasks themselves shouldn't have defaults, but the plugins which create them should set them. However, there are some cases where you want defaults, for example when the user can create additional tasks. In this case I think the easiest is to do it in the task constructor, eg, here, calling `inputDirectory.from(...)` in the ctor

One thing that concerns me here is if some properties (e.g. workingDir in Exec) doesn't work with delegated properties, as it likely hasn't been set yet in the constructor

Maybe you shouldn't extend the `Copy` and `Exec` tasks, and rather use the `FileSystemOperations#copy` and `ExecOperations#exec` from your task action.

workers can run in parallel, and tasks in different project can run in parallel, but tasks in the same project cannot without configuration cache (which prevents mutations to the project, making parallel task execution safe)

```  this@Build_gradle.sameName```
seems to work

`FileSystemOperations` has a `copy()` method.

I am not sure why that is not working (I think in general it looks like it should), but it’s kind of an outdated approach. (Some of the APIs might/should be deprecated soon… maybe…)

I would do it all through the configurations and use a USAGE attribute to match them.

On the producer side:
```configurations.create("specFiles") {
    isCanBeResolved = false
    isCanBeConsumed = true
    attributes {
        attribute(Usage.USAGE_ATTRIBUTE, objects.named("spec-files"))
    }
    outgoing.artifact(resourcesJar)
}
// No artifacts{} block!```
And this on the consumer side:
```val specFilesPath = configurations.create("specFilesPath") {
    isCanBeResolved = true
    isCanBeConsumed = false
    attributes {
        attribute(Usage.USAGE_ATTRIBUTE, objects.named("spec-files"))
    }
}

dependencies {
    specFilesPath(project(":producer"))
}```
See also a full sample here:

Consumer : <https://github.com/jjohannes/understanding-gradle/blob/main/13_Aggregating_Custom_Artifacts/my-build-logic/java-plugins/src/main/kotlin/my-java-application.gradle.kts#L6-L18|https://github.com/jjohannes/understanding-gradle/blob/main/13_Aggregating_Custom_[…]gic/java-plugins/src/main/kotlin/my-java-application.gradle.kts>
Producer: <https://github.com/jjohannes/understanding-gradle/blob/main/13_Aggregating_Custom_Artifacts/my-build-logic/java-plugins/src/main/kotlin/my-java-base.gradle.kts#L16-L26|https://github.com/jjohannes/understanding-gradle/blob/main/13_Aggregating_Custom_[…]uild-logic/java-plugins/src/main/kotlin/my-java-base.gradle.kts>

Now I I see that the problem is somewhere else (solving it should make it work with both approaches):

This is not “lazy”
```    from(zipTree(specFiles.singleFile))```


Should be:
```from(specFiles.elements.map { zipTree(it.first()) })```

Also, there is no need to jar the resources just to unjar them again, is there? That should just be unnecessary work and add an artificial manifest file in the result.

You could add as well just publish the directory with the resources and directly use it, either the result of `processResources` to also get eventual transformations, or the source of you want it.

Actually, iirc the `java-library` plugin should already publish such a variant that you can directly use in `consumer`. Make sure it is applied and have a look at `:producer:outgoingVariants` output.

Thank you <@U023HSZL88M> - that was the missing piece.

<@URQ797WRW> - Thanks for that. Yup, java-library produces a secondary variant called `resources` and that is exactly what I needed.

That is an interesting question. I was about to add typesafe accessors to sigstore-java, and now I’m inclined I’ll wait for the answer )

I filed <https://github.com/gradle/gradle/issues/22095>

Ended disabling all the things :disappointed: <https://github.com/apollographql/apollo-kotlin/pull/4409>.

The Groovy one should work in java. does it not?

No, there's an error

```Caused by: org.gradle.api.reflect.ObjectInstantiationException: Could not create an instance of type bla.bla.GreetingPluginExtension```

Ah I figured it out, the constructor needs to be `public`

Is there a way in Java I can get the string `"message"` from the class GerrintPluginExtension?

Gradle knows to turn method `getMessage()`  into a a property named `message` by removing the `get` and turning the first character after to lower case

It returns a `Property&lt;String&gt;` object

if I add a new method to the extension caled `getFooBar()`

then in the `build.gradle` i'll need to access it by setting `fooBar = "blabla"`

so Gradle knows how to turn the method name `getFooBar` into the property name `fooBar`

and I want to access that property name, not the property value

i believe you would do this in the same way that you would do this with standard java reflection for any property name.

Isn't there a way to access `propertyName` without reflection? :thinking_face:

I'm writing a test where I'm adding setting a value to the property `semver_gitRepoPath` via a command line argument `-PsemverGitRepoPath=abcd`

instead of hard-coding the string `-PsemverGitRepoPath=abcd`  I'd like to to something like

`"-P" + getSemver_gitRepoPath().getPropertyName() + "=abcd"`

alas, `getPropertyName` does not exist :pensive:

You cannot set arbitrary task or extension properties using Gradle properties anyway, so what's the point?

Never mind, I've found a reasonable workaround for what I was trying to do

`gradle.properties` is a properties file, not a way to fill object graphs.
If you want to add that semantic you either need to do it yourself or use some plugin that can do it.

Yes there is. The KGP plugin registers an extension named `kotlin` of type `KotlinJvmProjectExtension`

Any idea how I might access it's `KotlinJvmOptions` configuration? I am attempting to move the code below from a build script configuration, via task lookup, into a conventional plugin. I can't easily see how I might be able to do this via the `KotlinJvmProjectExtension`

```tasks.withType(KotlinCompile::class).configureEach {
   kotlinOptions {
      allWarningsAsErrors = true
      jvmTarget = JavaVersion.VERSION_11.toString()

      sourceCompatibility = JavaVersion.VERSION_11.toString()
      targetCompatibility = JavaVersion.VERSION_11.toString()

      freeCompilerArgs = freeCompilerArgs + "-Xexplicit-api=strict" + "-opt-in=kotlin.RequiresOptIn"
   }
}```


Yeah configuring the extension is quite different than configuring the task.

It depends on the options. But from the top of my head something like `kotlin.target.compilations["main"]` will get you the compilation options for the main source set.

`kotlin.target.compilations.configureEach {}` should work if you want to configure them all

That seems to be what I was looking for, thank you for the help!

out of curiosity : are you releasing your convention plugins  or using includeBuild ?

At the moment I am using `includeBuild`, but may start releasing them to a private artifact repository later on

Thanks. I reverted the includeBuild because of the performance penalty our build incurred : the dependency resolution for all modules ended up being done single threaded. which aligns with the squad blog post and the documentation

hello everyone, I have a build using `buildSrc` which contains both an actual custom plugin and various convention plugins. I was unable to reference the custom plugin by id from the the convention plugins, so I tried moving the custom plugin to a directory of its own and use an `includeBuild`. However it appears that doing so disables parallel execution for the dependency resolution step of all the projects in the build. this is probably what
&gt; _Because of the reliance on dependency substitution, composite builds may force configurations to be resolved earlier, when composing the task execution graph. This can have a negative impact on overall build performance, because these configurations are not resolved in parallel._
warns about but I don't understand why it behaves like this in this specific case.

The only alternative I could find is to imperatively `apply()` the plugin, is that the recommended practice ?

:wave: Hey, <@UES7RHBDZ>. The `jacoco-report-aggregation` plugin is bundled with Gradle and exists within the Gradle project. For example, here is the main class for <https://github.com/gradle/gradle/blob/v7.5.1/subprojects/plugins/src/main/java/org/gradle/api/plugins/TestReportAggregationPlugin.java|TestReportAggregationPlugin>.

thanks! my grep-fu was lacking, I wasn't able to find it when I looked earlier

Same as for other lifecycle tasks. If you run `build` it only runs in the projects of the main build and in the included builds only the absolutely necessary tasks are run. (Usually compiling and building the jar) So if you want the other semantic, make the lifecycle task of the root build depend on the respective lifecycle tasks in the included builds.

What is the right way to do that without causing issues with cross project configuration and eager task creation?

In this case there isn’t even a root project task with a matching name, sort of a feature rather than an issue IMO.

Thinking what I may do is just do a dynamic job on the CI pipeline that only gets included when changes to the gradle directory are detected. Run the included project directly in that case so the lifecycle invocation behavior just works on it again.

Didn't fully get it, but if it works for you, why not. :-)

How to do it depends on many factors. You could ensure every project has the task but just might not have work, or you could make that task a specific type for which you could filter, ...

right. last I checked the withType caused eager creation but its been a bit since I've had a look. Honestly thinking i'll just tackle it with the dynamic CI config. Then I am not trying to bend gradle into doing something it really really doesn't want to do off the shelf.

`withType` only eagerly creates if you directly give it a configure action. As long as you only get the tasks by type or use `configureEach`, you are fine regarding task configuration avoidance.

ahh ok, today I learned. so maybe worth an attempt to wire it in

This may be useful: <https://docs.gradle.org/current/dsl/org.gradle.api.Project.html#org.gradle.api.Project:property(java.lang.String)|Project#property(String)>

What happens if in your task's `doLast` you instead use `project.property("greeting.message")` to retrieve your property?

this works in the case where I use the command line

but if I only set `greeting.message` in the extension block:
```greeting {
   message="greeting1"
}```
then it results in an error:
```* What went wrong:
Execution failed for task ':greetingTask'.
&gt; Could not get unknown property 'greeting.message' for root project 'proj1' of type org.gradle.api.Project.```


The most ‘modern’ way to access such a _Gradle property_ would be through `project.getProviders().gradleProperty("greetings.message")`

You then have to pass that to your extension. For example instead of `getMessage().convention("greeting0")` above, you could do `getMessage().convention(project.getProviders().gradleProperty("greetings.message"))`

This is a common problem/pattern. That’s why <@UF9HQE743> and I have created a plugin that basically generates this setup for you. Maybe it fits your use case: <https://github.com/gradlex-org/build-parameters>

This requires the `GreetingPluginExtension` class to have access to the `project` instance

Yes… right. Sorry. I typically set the convention in the plugin and not in the constructor. So do `greeting.getMessage().convention(project.getProviders().gradleProperty("greetings.message"))` right after you created the extension.

Or you can add `Project project`  as parameter to the constructor and add `@Inject` to the constructor.

With the first solution, the extension can also be an `interface` without a constructor.

Do you have a complete code example that uses this pattern?

Also, how do I set a default value for the property when I use this pattern?

I'm getting this error:
```* What went wrong:
A problem was found with the configuration of task ':greetingTask' (type 'GreetingTask').
  - In plugin 'extension_example.greeting' type 'extension_example.GreetingTask' property 'message' doesn't have a configured value.
    
    Reason: This property isn't marked as optional and no value has been configured.
    
    Possible solutions:
      1. Assign a value to 'message'.
      2. Mark property 'message' as optional.
    
    Please refer to <https://docs.gradle.org/7.5.1/userguide/validation_problems.html#value_not_set> for more details about this problem.```

Yes, if you run without `-P` , right? You should be able to chain another convention:

`greeting.getMessage().convention(project.getProviders().gradleProperty("greetings.message").convention("defaultMessage"))`

If you clone this example: <https://github.com/gradlex-org/build-parameters/tree/main/samples/basics>
and `build` it, the code generated by the “build-parameters” plugin should follow this pattern. You can find that in `build/generated-src`

OK the `convention` chaining works in providing a default value, but it doesn't identify it when I add `-Pgreeting.message="greeting2"` to the command line

oh silly me I was mixing `greeting` and `greetings` with the extra s

Np. I think I introduced that extra `s` when I gave the samples. :smile:

I corrected the mixup and it still doesn't work :confused:

I'll try using your plugin on my greeting example

How do you connect the Extension to the Task Input? That bit is missing as far as I can tell in your original post.

`greeting.getMessage().convention(project.getProviders().gradleProperty("greetings.message")` means the value of the extension property will take priority over the command line parameter, correct? Generally you want it to be the other way around where the command line parameter takes priority, right?

I would like the command line param to take priority, yes

<@U023HSZL88M> here's my current setup:

```// GreetingsPlugin.java

package extension_example;

import org.gradle.api.Project;
import org.gradle.api.Plugin;
import org.gradle.api.provider.Property;

import javax.inject.Inject;

abstract class GreetingPluginExtension {
    abstract Property&lt;String&gt; getMessage();

    @Inject
    public GreetingPluginExtension(Project project) {
        getMessage().convention(project.getProviders().gradleProperty("greeting.message")).convention("greeting0");
    }
}

public class GreetingsPlugin implements Plugin&lt;Project&gt; {
    public void apply(Project project) {
        GreetingPluginExtension extension = project.getExtensions().create("greeting", GreetingPluginExtension.class);
        project.getTasks().register("greetingTask", task -&gt; {
            System.out.println(extension.getMessage().get());
        });
    }
}```


```// build.gradle
plugins {
    id 'extension_example.greeting' version 'unspecified'
}

repositories {
    mavenLocal()
}

greeting {
    message = 'greeting1'
}```

when I comment out the `greeing{}`  block and run `gradle greetingTask -Pgreeting.message="greeting2" ` I get

```&gt; Task :greetingTask
greeting0```

The second `convention` is in the wrong place so that it overrides the first one:
This
`...gradleProperty("greeting.message")).convention("greeting0")`
should be
`...gradleProperty("greeting.message").convention("greeting0"))`

so like this?:
`getMessage().convention(project.getProviders().gradleProperty("greeting.message").convention("greeting0"));`

```error: cannot find symbol
        getMessage().convention(project.getProviders().gradleProperty("greeting.message").convention("greeting0"));
                                                                                         ^
  symbol:   method convention(java.lang.String)
  location: interface org.gradle.api.provider.Provider&lt;java.lang.String&gt;```

Ah right. So I was wrong. Shouldn’t try this from memory.

Would you like me to upload the complete example to a github repo?

When you access the property from within your task, try something like:
```String message = project.getProviders().gradleProperty("greeting.message").getOrElse(extension.getMessage().get())```

Jendrik wrote something and then deleted it?

I tried doing this in the constructor:
`getMessage().convention(project.getProviders().gradleProperty("greeting.message").orElse("message0"));`

this works, however it treats the value in the `greeting {}`  block with MORE precedence over the command line

Yes. Sorry for deleting that again. That’s what I meant.

But yes, the order is wrong for your case.

Yes, in that case, what Eric proposes is better.

however it is quite cumbersome to add that line to each and every property in the plugin i'm migrating.. hmmm

I still havent given Jendrik's build parameter plugin a try

But, if you want to treat `message` as a task input later, you have to check. Because accessing properties directly from within the task is bypassing declaring them as inputs correctly.

I'll try using `@Input`  now and see if that works

The plugin, basically neglects the use case you have though. It just gives you an extension to “build parameters” (Gradle properties) for which you can define a default value. You can’t change these values anymore in the build.

This is on purpose, because we think it is just overly complicated if you set/change the value in different places in the build. Maybe just setting a default is enough.

I'm not sure I understand your point.

The build parameters plugin does not allow setting a value from several places with a defined precedence? (such as command line &gt; extension block &gt; default value)

In you case, you can also set the value where you now have `.convention("greeting0")` and then *not* change it in another place in the build again. Then the `-P` value wins over the value you set there. And that’s more or less what the plugin is also doing. Only that the code the plugin generates actually prevents you from changing the value (it’s using Providers instead of Properties).

It allows you to use `-P` and you can define a default value.
You can not change things in the _extension block_ (the extension is read-only you could say)

Oof this is getting somewhat complicated :face_with_spiral_eyes:

I think I need to read up on Gradle providers to get a better grip of this

Sorry. Some topics are mixed up here now.