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

Gradle Community

`from(jarTask)` should get you what is needed.

I'm trying to publish a plugin, and using the Shadow plugin, but I'm getting an error

&gt; Please configure the `shadowJar` task to not add a classifier to the jar it produces
<https://plugins.gradle.org/docs/publish-plugin#shadowing|The Publish Plugin docs say it should just work>

&gt; Starting with version 1.0.0 the Plugin Publish plugin can automatically interact with the com.github.johnrengelman.shadow plugin, if applied. It will automatically publish the jar produced by the `shadowJar` task, as the main artifact. Note that this interaction requires the usage of Gradle v6.0.1 or later, in order to work properly.
I'm using Publish Plugin v1.1.0, Shadow v8.1.0, and Gradle v8.0.1. So what am I missing?

You cannot "call" a task, you can just define dependencies between tasks.
And while you can configure one task from the execution phase of another one, you shouldn't, especially in the light of upcoming configuration cache that disallows that.

Okay, so knowing that, what is a trivial solution for this?

There most probably is none.
Especially as you said `-PsomeOption` which means you are not configuring a task, but you set a Gradle property.
You cannot set a Gradle programmatically.
You can set an `extra` property of the same name and depending on how the consumer of the property reads it, it might take precedence.
But if for example the consumer uses `providers.gradleProperty` it would not be taken into account.

I'm not 100 % sure, but I don't think that is correct. It depends on how you use it. If you use it for example to depend on them, for example to depend on all projects for jacoco report aggregation or similar, it should be perfectly fine. If you use those methods to configure the projects you are given, then it's bad. And for that purpose also the other methods you mentioned would be bad.

Hi all, have couple questions to ask

1. Why dependency substitution from `module` to `project` and vice versa trigger dependency resolution? 
2. Is there a way to avoid this?
As for the context, I’m trying to make the warning emitted by <https://cs.android.com/android-studio/platform/tools/base/+/mirror-goog-studio-main:build-system/gradle-core/src/main/java/com/android/build/gradle/internal/DependencyResolutionChecks.kt;l=1;bpv=0|AGP> gone. But, putting the dependency substitution after `taskGraph.whenReady` means we will not have a right task graph.

The tasks are in the same project, right? `--parallel` is only affects multiple subprojects

<https://docs.gradle.org/current/userguide/performance.html#parallel_execution>

&gt; Most projects consist of more than one subproject. Usually, some of those subprojects are independent of one another; that is, they do not share state. Yet by default, Gradle only runs one task at a time. To execute tasks belonging to different subprojects in parallel, use the `parallel` flag

Ahh gotcha -- ok, that makes sense then, yes they're part of the same project. Do you know if Gradle does support parallel task execution for tasks within the same project? :thinking_face:

<https://docs.gradle.org/current/userguide/performance.html#enable_configuration_cache>
&gt; The configuration cache enables additional benefits as well. When enabled, Gradle:
&gt; • Executes all tasks in parallel, even those in the same subproject.

if you really wanted to get into the guts of Gradle, then it is possible to write tasks that do work in parallel.

<https://docs.gradle.org/current/userguide/worker_api.html>

But this is pretty specialised

Ahh that's great to know :point_up: I'm sure it'll be useful

<@U019L3NM4PK> enabling the configuration cache seemed to do it :tada:!

<https://scans.gradle.com/s/kucg6jxuau6xi/timeline>

I have written in a couple of projects
```tasks.test {
    // Re-use downloaded artifacts to speed up test times
    environment("GRADLE_RO_DEP_CACHE", File(gradle.gradleUserHomeDir, "caches"))
}```
which is not entirely what you asked for, but sharing the parent's dependency cache with the child does help with build times

it doesn't seem to help much locally though

1. `./gradlew clean`
2. `./gradlew check` - 2 minutes
3. add 
```    tasks.withType&lt;Test&gt;().configureEach {
      // Help speed up TestKit tests by re-using     dependencies cache (this really helps GitHub Workflows)
      // <https://docs.gradle.org/current/userguide/dependency_resolution.html#sub:shared-readonly-cache>
      environment("GRADLE_RO_DEP_CACHE", gradle.gradleUserHomeDir.resolve("caches"))
    }```
4) `./gradlew clean`
5) `./gradlew check` - 2 minutes
6) `./gradlew check` - 30 seconds

Looks like it's
```id("org.gradle.kotlin.kotlin-dsl") version "4.0.6"```

But then you have to track that version number as you update Gradle

Yeah, this is what I want to avoid. The version is even not published in the user guide.

We are seeing tasks with short execution times (&lt;1 sec) and long fingerprinting input time (~30 secs). What influences the fingerprinting time and what (if anything) can be done to improve its performance? Note that this is only for the initial execution of the task, subsequent executions do not have the long fingerprinting time.

If you're using Kotlin you can always add extension functions:
```fun RepositoryHandler.myAwesomeRepo()```

You're right, but what to do if i'm not using Kotlin at this moment?
With `DependencyHandler` I can create some useful wrappers even to be used in Groovy, but not with `RepositoryHandler`.

Also, extension functions can't be scoped per-module, as Gradle Extensions allow you to do.

The least classes formally are `ExtensionAware` but actually practically all domain objects and also all other objects created by Gradle with means like `objects.newInstance` or `container.register` or `container.create` or similar are on-the-fly decorated to be `ExtensionAware`.

You just have to cast most things to `ExtensionAware` to use the interface methods.

You will not get type-safe accessors for usage in Kotlin DSL for some of them.
But for `RepositoryHandler` you indeed should get them by now.

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

Oh, that's nice!

Yes, this is what I see when debug build file, did you consider making ExtensionAware as part of public API for this particular class?

I don't consider anything, I'm just a user like you.
I'm not even a Gradle Fellow or in any way affiliated to Gradle.

But as far as I know, it is pretty awkward to formally make a class `ExtensionAware` which is the cause most are not

Oh, sorry, my mistake. I think casting is the way to go for now. Thank you for your support!

But here you can find a discussion about the very topic: <https://github.com/gradle/gradle/issues/7547>

Why are you asking here? It is a Gradle plugin. You should probably ask the vendor of that plugin. :-)

the vendor has been acquired by gradle inc so i'd assume the responsibility falls into the hands of gradle inc now.

<https://gradle.com/press-media/gradle-inc.-acquires-triplequote-to-expand-developer-productivity-solutions-footprint/>

You should use a CommandLineArgumentProvider with jvmArgumentProviders:
```testTask.configure {
    jvmArgumentProviders.add(
        JavaAgentArgumentProvider(someConfig))
}

class JavaAgentArgumentProvider(
    @get:Input val javaagent: FileCollection
) : CommandLineArgumentProvider {
    override fun asArguments() =
        listOf("-javaagent:${javaagent.asPath}")
}```

If I have a number of template files and fragments that are used by multiple projects in a single build where is best place to put them? Is it good practice, or acceptable to have multiple projects referencing source files outside their individual project directories? Should I be creating a project to contain them, and publishing them via a configuration?!

I think I figured it out:
```        from(files(task).asFileTree.filter {
            it.path.endsWith("dir1/dir2/file")
        })```


This took the better part of an hour :disappointed:

`FileTree` is clearly powerful but I don't really understand how it works, particularly when derived from some other file collection, e.g. by filtering, merging, calling `asFileTree`...

Does this help?

&gt; To convert a file tree to a flat collection, use the `FileTree.getFiles()` property.
<https://docs.gradle.org/current/userguide/working_with_files.html#sec:file_trees>

That performs eager evaluation. So I can't use it

I need to copy a file _that a task produces_ in a subdirectory, so evaluation of the `FileTree` has to wait until execution time

Alarmingly, I noticed that calling something like `getFiles()` on a `Buildable` with build dependencies just silently returns an empty file set, instead of throwing an exception

usually it’s best to try and use a TaskProvider, so you could do

```val files: Provider&lt;Collection&lt;File&gt;&gt; = 
   task.map { it.outputFiles.myCustomFlattenFilteringOperation() }
from(files)```
Gradle will know that it needs to run `task` in order to compute `files`

but if you can’t, you can try and do

```providers.provider { task.files... }```

to make a custom provider (but then Gradle doesn’t realise there’s a task dependency)

and I think with file collections you can even just pass in a lambda and it’ll be lazily evaluated

```from({ task.files... })```

I don't see `task.outputFiles` but I do see `task.outputs.files`

I know there was a deprecated property like `task.outputDirectory` which I think was removed in Gradle 8

yeah sorry, `.outputFiles` is psuedo-code :)

you can set the console to output plain text by setting it in your home folder:

`C:\Users\$USER\.gradle\gradle.properties`

just add the following text into that file (creating it if it doesn't exist):

`org.gradle.console=plain`

I don’t think this is about UTF-8, looks like ANSI codes that PowerShell doesn’t understand.

But I’m not sure what to do about it, except what David says; I’m no Windows user.

<@UNWHSMML1> I do not know how it works when I set encoding to UTF-8 in PS priorities window. Before changing to that, the characters looks good, so  I think Gradle has some issues when processing UTF-8 in console.
And my IDEA console display correctly using default config.

BTW  <@U04BGKSKGBY>’s solution resolved my issue, thanks a lot.

Also, I was considering setting things up like <@URQ797WRW> suggests <https://discuss.gradle.org/t/right-way-to-generate-sources-in-gradle-7/41141/3|here>, i.e. that the `srcDir` is not explicitly sets but taken from the output of the generate step, but can’t get it to work. <https://github.com/skagedal/hahabit/pull/5/files|Here is my attempt>, but I get stuck in how to get the output dir from the `TaskProvider&lt;GenerateTask&gt;` …

Actually with the OpenAPI Generator Gradle plugin it is a bit compilcated.
Because the `java` generator does by default not just produce the Java sources, but a full Gradle build.
It is probably more targeted to being one-time generated and then checked in which I greatly dislike.
But due to that, the whole generated Gradle build is the output of the task and not just the sources you are interested in.
If the `GenerateTask` would have the proper outputs, i.e. the root directory of the sources files, it would work much better.
It then just is
```diff --git a/build.gradle b/build.gradle
index 1e8bb35..3c55eb7 100644
--- a/build.gradle
+++ b/build.gradle
@@ -65,13 +65,13 @@ jacocoTestReport {
 }

 openApiValidate {
-       inputSpec = 'openapi.yaml'
+       inputSpec = file('openapi.yaml').absolutePath
 }

 check.dependsOn tasks.openApiValidate

 def generateHahabitApi = tasks.register('generateHahabitApi', GenerateTask) {
-       inputSpec = 'openapi.yaml'
+       inputSpec = file('openapi.yaml').absolutePath
        generatorName = 'java'
        outputDir = "${buildDir}/generated/sources/openapi"
        configOptions = [
@@ -80,13 +80,10 @@ def generateHahabitApi = tasks.register('generateHahabitApi', GenerateTask) {
        ]
 }

-compileTestJava.dependsOn generateHahabitApi
-
 sourceSets {
        test {
                java {
-                       // Wbat to put here? Can't do `generateHahabitApi.outputDir` since `generateHahabitApi` is a task provider.
-                       srcDir "${generateHahabitApi}/src/main/java"
+                       srcDir generateHahabitApi
                }
        }
 }```
Actually you can even do that, but it is a bit unclean, as the the sources do not get properly set up in the IDE, and you also have the generated tests of the generated project in your classpath, namely all `.java` files in that generated project.

So to have it a bit cleaner with the OpenAPI Generator plugin, it would more be like this to only generate the files you really want and have them cleanly integrated in the build and IDE:

```diff --git a/.openapi-generator-ignore b/.openapi-generator-ignore
new file mode 100644
index 0000000..a42e0e8
--- /dev/null
+++ b/.openapi-generator-ignore
@@ -0,0 +1,2 @@
+/build/generated/sources/openapi/main/java/**
+!build/generated/sources/openapi/main/java/org/**
diff --git a/build.gradle b/build.gradle
index 1e8bb35..67a4543 100644
--- a/build.gradle
+++ b/build.gradle
@@ -65,28 +65,31 @@ jacocoTestReport {
 }

 openApiValidate {
-       inputSpec = 'openapi.yaml'
+       inputSpec = file('openapi.yaml').absolutePath
 }

 check.dependsOn tasks.openApiValidate

-def generateHahabitApi = tasks.register('generateHahabitApi', GenerateTask) {
-       inputSpec = 'openapi.yaml'
+openApiGenerate {
+       inputSpec = file('openapi.yaml').absolutePath
        generatorName = 'java'
-       outputDir = "${buildDir}/generated/sources/openapi"
+       outputDir = "${buildDir}/generated/sources/openapi/main/java"
+       generateApiDocumentation = false
+       generateApiTests = false
+       generateModelDocumentation = false
+       generateModelTests = false
        configOptions = [
+               sourceFolder: '',
                library: 'native',
                useJakartaEe: 'true'
        ]
+       ignoreFileOverride = file(".openapi-generator-ignore").absolutePath
 }

-compileTestJava.dependsOn generateHahabitApi
-
 sourceSets {
        test {
                java {
-                       // Wbat to put here? Can't do `generateHahabitApi.outputDir` since `generateHahabitApi` is a task provider.
-                       srcDir "${generateHahabitApi}/src/main/java"
+                       srcDir tasks.openApiGenerate
                }
        }
 }```
After you did these changes, you should once manually delete the `build/generated/sources/openapi` directory, or run `clean` task, as the directory is not wiped automatically with the new setup.

Lucky for you I did exactly this in a project not long ago, so could copy over some setup for you :slightly_smiling_face:

Very cool, thanks! I’ll try this later tonight hopefully and report back. It does make sense in any case to not generate a bunch of stuff you don’t need or want…

No.  Only Error is higher than quiet.  <https://docs.gradle.org/current/userguide/logging.html>

Specifically at <https://docs.gradle.org/current/userguide/logging.html#logLevels>

ah okay, I think the table should have that same order too

Well, it is more or less in the same order.
Just that "giving no option" is listed first as it is the default.

But feel free to suggest moving it between `-i` and `-w`  via feature request or pull request. :slightly_smiling_face:

<https://github.com/gradle/gradle/pull/24173> Thanks for the PR. Should be merging soon.

How does one filter to a single dynamic test via gradle's junit5 runner? Google was not helpful at all!

That's how it works, you could use configure-on-demand but it's considered harmful (because you can shoot yourself in the foot if you do any cross-project configuration)

`android` should be available at compile time, unless you're referring to `productFlavors` not being populated? The problem is that product flavors can be declared arbitrarily around one's build; maybe in a plugin, maybe in an obscure build script. To do some computation on the `productFlavors` you should use the `.all` method:

```task decideWhichTestToRun() {
  android.productFlavors.all {
    // ...
  }
}```
Although that doesn't fit your use case. tbcf, your use case may be an edge case. You _could_ do something like this:
```task decideWhichTestToRun() {
  afterEvaluate {
    // ...
  }
}```
But that generally indicates a design error. Ideally you would have tests that always run- and then tests that _also_ run if under a certain flavor.

doesn't that have the same issue as `provider {}`? it doesn't carry any dependency information with it

&gt; it doesn't carry any dependency information with it
what do you mean with that?

```tasks.named("foo").flatMap { it.outputFile }```
without executing anything, it carries information that it is built by `:foo`
```provider { tasks.getByName("foo").outputFile.get() }```
this doesn't

Well, I was thinking overall for plugin extensions, but I would expect that if a task has a property it could be user in the similar way. So for setting a prop in a task

```task.named&lt;Foo&gt;("foo").configure { it.prop.set { ... } }```

Not sure what you are asking about.
If what you ask is, to remove `convention` and `set` methods that take a value directly and only have same-named methods that take a supplier, so that it is always caclulated lazily, then no that is not a good idea.
If you have a value already, you would artificially delay it and thus add artifical totally unnecessary operation time.
Besides that you then also very easily add ordering traps again without thinking about it.
A user of the API has to decide whether he calculates or already has a value eagerly and set it, or whether he sets some provider that calculates it lazily and maybe also carries task dependency information.

We ran into another change of behavior when updating to 8.0.2. I've raised an issue here: <https://github.com/gradle/gradle/issues/24172>

If you set it on that project specifically, the issue persists?

In the settings file. If I do it in the project build.gradle it works fine. But I would like to define it globally for all project (btw I tried setting it on rootproject as well)

maybe you can use other lambdas, like `gradle.beforeProject` or `gradle.projectsLoaded`

unfortunately, doesn't help :disappointed:

The easiest is, to not set it in code at all.

I usually set those two in the root projects `gradle.properties`, which makes them available to all subprojects too

Unless you need to calculate them in any way of course

I was sure that was gonna help, but to my surprise the result is the same - group is accessible during sync, but empty during publishing - both project.group and rootProject.group. And the same error occurs.

Even weirder - it breaks the publication for projects that worked before, but with a different error:
```&gt; Failed to publish publication 'maven' to repository 'mavenLocal'
   &gt; Invalid publication 'maven': groupId ("com.example") is not a valid Maven identifier ([A-Za-z0-9_\-.]+).```

yeah, that helped for the second issue :smile: but still empty for the plugin project. I'm probably doing something stupid there as well...

Is it really a subproject, or is it a subbuild?

All 3 are included via include. Not via includeBuild

Do you maybe explicitly set it to empty in the plugin project?

If again no, I'm out of ideas without an <https://stackoverflow.com/help/mcve|MCVE>

looks like another plugin/config is overriding it to null

maybe `gradlePlugin` clause is doing sth like that...

if anyone stumbles upon a similar problem.

I had two `settings.gradle.kts` files. One in the root project and one in the plugin project :face_palm: Completely missed that, it was some garbage after migration from one repo to another...

What do you mean with "can have a null string"?
If you set it to `null`, the convention value is used.
If there is no convention value or you set it to `provider { null }`, the provider has no value and gives an exception if you query it for its value.
(This inconsistency is topic of <https://github.com/gradle/gradle/issues/14768> btw.)

What I mean is `Property&lt;String&gt;` is like Java development (at least old versions). You get the null in runtime if you don't do manual checks with `if` or whatever.

I would like to have null safety to ensure a property cannot be null, currently you can

```val someProp: Property&lt;String&gt; = objects.property&lt;String&gt;().convention() // you don't set any value```
And it will crash, but it shouldn't compile.

Based on that issue, what I mean is, the next snippet shouldn't compile in some situation where `null` must not be valid, only if explicitly the type is `String?` (or there is a `NullableProperty`)

```someProperty.set(null)```

And `restoreConvention` is the way I would choose so in the future we can have null safety on properties

Setting to `null` does not set it to `null`, it sets it to the convention or to unset if there is no convention. You can chain providers, so that if it is unset a different provider is evaluated and so on. No provider can have a `null` value currently. 

And regarding "is like Java development", well, it *is* Java development. It is a Java class.

Probably because you are using the Spring DM plugin

You should remove it and use Gradle's built-in support for platforms (BOMs)

Which is even recommended by the maintainer of the Spring Dependency Management Plugin.

Is there a standard way to add assertions to the actual class path of a project in Gradle? 

I guess something like this:
```
configurations.runtimeClasspath.incoming.afterResolve {
   // whatever you want to check
}```

Tested: Gradle's native BOM support solves the problem. More observations: SpringBoot documentation does not clearly recommends to avoid using their plugin. "io.spring.dependency-management" plugin is generated in a fresh project via SpringInitializr.

Thanks Cédric, I will use that approach.

The reasoning behind - we have multiple modules with hundreds of transitive dependencies plus dependency resolution. I'm looking to make the whole process more predictable to catch sudden changes to the classpath. A butterfly effect

You are right with your observations.
I didn't say the docs or tools recommend it.
I said the maintainer of that plugin recommends it: <https://linen.dev/s/gradle-community/t/2579116/what-is-the-proper-way-to-apply-a-bom-in-a-library-project-i#a7d4a60a-ab60-48dc-8477-f3f4462d1e6a|https://linen.dev/s/gradle-community/t/2579116/what-is-the-proper-way-to-apply-a-bom-in-a-library-project-i#a7d4a60a-ab60-48dc-8477-f3f4462d1e6a> :-)

Well, their docs at least say that you get faster builds with the built-in BOM support: <https://docs.spring.io/spring-boot/docs/3.0.4/gradle-plugin/reference/htmlsingle/#managing-dependencies|https://docs.spring.io/spring-boot/docs/3.0.4/gradle-plugin/reference/htmlsingle/#managing-dependencies>

`dependencies` is special, most task names do execute in all projects

Use case: Find a dangling dependency from a CVC/OWASP security bulletin in a huge codebase that has thousands of transitive dependencies

One knows that the dependency _is_ used somewhere (it’s downloaded to the Gradle cache after all!), but from where exactly is hard to tell, if you have multiple assembly points / external libraries.

well, there's a couple ways you could go about that

1. loop over every subproject and run the dependencies task on it
2. define a task by a different name, `allprojects { task reallyDependencies { dependsOn 'dependencies' } }`
3. add a constraint `allprojects { dependencies { constraints { } } }` that blocks the dependency, try to build and see what breaks
4. build with build scan and it should be visible

maybe more options but that's just what I could come up with for now

How about just calling b+a instead of a+b?

Because `a` is an existing `classpath` property of a task. :slightly_smiling_face:

Isn't `plus` returning a new file collection anyway?

Silly me, `classpath = project.files(newItem) + classpath` does the job. Thanks!

Check out <https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin|https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin>

The Android in the name is just bad initial name choosing. But actually the plugin does the opposite of what you asked for was what you asked for is bad practice

It tells you libraries you depend on but don't use and it tells you libraries you use but don't declare but for just have as transitive dependencies and some more.

Yeah, I noticed that. We have a lot of explicit dependencies in build.gradle files in various projects that I don’t think should be there. Some of those would probably be covered by the “unused” detection here, so that’s great!

I don’t necessarily agree that what I’m trying to accomplish is bad practice, but I have no need to discuss that right now, just looking for the tools. :slightly_smiling_face:

As a simple example, I don’t think it would be a good idea to have a dependency on `org.springframework.boot:spring-boot-starter-web` and then also a explicit one on `org.springframework:spring-web`. I want the dependencies that are tested together as the Spring Boot package.

Yeah, ok, for things like Spring Boot it is slightly different, as its purpose is to use the transitive dependencies. For that you can define in the dependency analysis plugin that it is ok to use dependency X transitively from dependency Y, so you don't get a complaint.

I see two strange things. 1. That no repo is configure though you applied the foojay plugin. 2. That it searches for any vendor when you configured Azul explicitly. Are you sure you are running the build your are modifying?

Thanks for the reply.  The project is open source so let me share some more information later today when I’m at a computer.

This pull request contains commits to demonstrate the issue: <https://github.com/zcash/zcash-android-wallet-sdk/pull/942>

(I had to update the Protobuf gradle plugin to resolve a different compatibility issue with Gradle 8.0+).  The last two commits include configuring the toolchain download plus the explicit setting of the toolchain, which I’m doing to work around an incompatibility with KSP).

The CI build job demonstrates the issue happening, without you having to check out and build the project.  (This particular project requires Rust, so setting up a build locally requires a bit of effort).

You just defined its default version if used in a `plugins { ... }` block without version by having it in `pluginManagement { plugins {... } }`.
To apply it, you have to add it to the top-level `plugins { ... }` block.

Btw. I'm *not* in any way affiliated to Gradle.
I'm not even a Gradle Fellow.
I'm just a user like you. :wink:

I’ll be able to test it in a few hours, but that’s certainly going to resolve it.