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

Gradle Community

<https://docs.gradle.org/7.3/release-notes.html#support-for-java-17>

It's strange to be reluctant to upgrade to 7.3. You should actually upgrade as soon as you can.

<@UMG417LGH> I've seen that. And I am personally also surprised.

<@UAFGSU86M> besides the compatibility matrix - should they expect any issues with 7.2 + java 17 ?

Java 17 is only officially supported since 7.3, so I'd say yes, they should expect issues by not ugprading

what do you mean “also surprised”? I’m just pointing out running a gradle build with java 17 is supported since 7.3, there’s no surprise on my end :thinking_face:

What’s the reason they don’t want to upgrade?

no issues so far with 7.2 + j17. Also gradle upgrades can be a bit ... troublesome ?

Personally in all projects I have just merged the Renovate/Dependabot Gradle pull request without having to do any fix in almost 99% times.

The only issue is forgetting to remove unnecessary feature flags

can you elaborate more please about the "Renovate/Dependabot Gradle" ? what do you mean by this ?

Renovate/Dependabot creates a PR for any new Gradle Wrapper version when it is available, and I can just merge it without doing anything because it is completely compatible and I find no issues.

Given the <https://docs.gradle.org/current/userguide/java_plugin.html#lifecycle_tasks|java plugin’s lifecycle>, you don’t want to have assemble depend on the code generation, as that’s way too late in the lifecycle. Compilation happens many steps before, which is what gradle is flagging here.

so, what would you suggest? Give up the dependency and call it manually?

I think you get implicit dependencies if you add the generated folder to the main sourceset though. That would allow gradle to figure out the dependencies by itself.

this should do it?
```sourceSets {
    main {
        java.srcDir("$buildDir/generated")
    }
}```


I just tried: deleted the generated code, run `assemble` and got error because the code supposed to be generated wasn't there..

it might be `sourceSets.main.kotlin`. Not sure how java and kotlin relate to eachother.

if implicit doesn’t work, you can always be explicit about it: `compileKotlin.dependsOn(generateCode)`, as that’s the task that actually requires the generated code

`compileKotlin.dependsOn(generateCode)` did do it indeed, thanks
now I get the same for `sourcesJar` and I'll do the same

does your generateCode task mark the generated folder as its output? perhaps gradle doesn’t see the link :thinking_face: because chasing down all these dependencies is why you’d like for gradle to do it implicitly

<https://github.com/scijava/gradle-catalog/blob/master/buildSrc/src/main/kotlin/core/GenerateCode.kt#L19|yep>

it's weird though, Gradle complains about `sourcesJar`
&gt; &gt; Task :generateCode
&gt; &gt; Task :compileKotlin UP-TO-DATE
&gt; &gt; Task :compileJava NO-SOURCE
&gt; &gt; Task :pluginDescriptors UP-TO-DATE
&gt; &gt; Task :processResources UP-TO-DATE
&gt; &gt; Task :classes UP-TO-DATE
&gt; &gt; Task :inspectClassesForKotlinIC UP-TO-DATE
&gt; &gt; Task :jar UP-TO-DATE
&gt; &gt; Task :javadoc NO-SOURCE
&gt; &gt; Task :javadocJar UP-TO-DATE
&gt; 
&gt; &gt; Task :sourcesJar
&gt; Execution optimizations have been disabled for task ':sourcesJar' to ensure correctness due to the following reasons:
&gt;   - Gradle detected a problem with the following location: '/home/elect/IdeaProjects/gradle-catalog/build/generated'. Reason: Task ':sourcesJar' uses this output of task ':compileJava' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to <https://docs.gradle.org/7.4.2/userguide/validation_problems.html#implicit_dependency> for more details about this problem.
But if I try to
```getByName("sourcesJar") { dependsOn(generateCode) }```
then
&gt; Task with name 'sourcesJar' not found in root project 'gradle-catalog'.


Possibly you can declare an (implicit) dependency between the task and the source set using Gradle’s `builtBy` function.
See an example in this section:
<https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:link_output_dir_to_input_files>

note also that you don’t need the `getByName` if you use kotlin dsl, this task has an accessor: `tasks.sourcesJar`

It depends whether the goal is to include the sources only into the `sourcesJar` artifact, or to actually compile them and include in the binary artifact. In the latter case, I think, `sourcesJar` is the wrong path, and the generated sources must be included in the `main` source set (after which they will automatically be included in the `sourcesJar`).

&gt;  note also that you don’t need the `getByName` if you use kotlin dsl, this task has an accessor: `tasks.sourcesJar`
I can't see it

<@U03K4EQUDQF> the generated source code should be treated the same as traditional source code, that is, compiled and included in the binary artifact.
I think I'm already including the in the `main` source set
```val SourceSet.kotlin: SourceDirectorySet
    get() = project.extensions.getByType&lt;KotlinJvmProjectExtension&gt;().sourceSets.getByName(name).kotlin

sourceSets {
    main {
        kotlin.srcDir("$buildDir/generated")
    }
}```


If you do it this way, I suppose, Gradle does not see the direct dependency between the `main` source set and the output of the task, because they are connected only via the directory name.

then what do you mean by
&gt; generated sources must be included in the `main` source set (after which they will automatically be included in the `sourcesJar`
how shall I do it?

By that I mean that you still want to include the generated sources in the source set, but you need to do it in a way that introduces a dependency between the source set and the `generateSources` task.

and that's where `builtBy` comes into play?

ok, so, `builtBy` looks to be available only on `Property`s, how can I use that in my case? I'd need somehow to have the input files for `kotlinCompile` call `builtBy(generateCode`

```sourceSets.main.kotlin.srcDir("$buildDir/generated", "builtBy" to "generateSources")```
I believe this should work

I don’t think there is an overload in Kotlin the accepts the map. Is there?

I think I found a solution. `builtBy` was in the right direction, but not available in the scope we want.

oh, sorry, you can only specify that on the output of the sourceset, so
```sourceSets.main.output.dir("$buildDir/generated", "builtBy" to "generateSources")```


First of all, I think you should remove the custom `kotlin` extension that you declare, to not get confused:
`val SourceSet.kotlin: SourceDirectorySet`

After that all you need to do is this:
```kotlin {
    sourceSets["main"].kotlin.srcDir(generateSources.get().outputs.files)
}```
The important difference with all the approaches above is that we have a live instance of `generateSources` task, and we take the reference to it’s output file collection. This collection _tracks dependencies_. Because of this the main source set now depends on the `generateSources` task, and you don’t need to duplicate the `"$buildDir/generated"` path at all (which is not advised anyways).

Then, running a `jar` task would execute the `generatedSources` task automatically:
```$ ./gradlew --console plain :lib:jar 
&gt; Task :lib:generateSources
&gt; Task :lib:compileKotlin FROM-CACHE
&gt; Task :lib:compileJava NO-SOURCE
&gt; Task :lib:processResources NO-SOURCE
&gt; Task :lib:classes UP-TO-DATE
&gt; Task :lib:inspectClassesForKotlinIC
&gt; Task :lib:jar```
(ignore the `:lib` prefixes, it’s just my local setup)

ok, I just tried, only
```tasks {
    ..
    kotlin.sourceSets["main"].kotlin.srcDir(generateCode.get().outputs.files)
}```
running `assemble`, I see `generateCode` is called properly before `compileKotlin` (and the generated directory is also properly marked by Idea as src folder) but I do still get the warning on `sourcesJar`
&gt; &gt; Task :generateCode
&gt; &gt; Task :compileKotlin UP-TO-DATE
&gt; &gt; Task :compileJava NO-SOURCE
&gt; &gt; Task :pluginDescriptors UP-TO-DATE
&gt; &gt; Task :processResources UP-TO-DATE
&gt; &gt; Task :classes UP-TO-DATE
&gt; &gt; Task :inspectClassesForKotlinIC UP-TO-DATE
&gt; &gt; Task :jar UP-TO-DATE
&gt; &gt; Task :javadoc NO-SOURCE
&gt; &gt; Task :javadocJar UP-TO-DATE
&gt; 
&gt; &gt; Task :sourcesJar
&gt; Execution optimizations have been disabled for task ':sourcesJar' to ensure correctness due to the following reasons:
&gt;   - Gradle detected a problem with the following location: '/home/elect/IdeaProjects/gradle-catalog/build/generated'. Reason: Task ':sourcesJar' uses this output of task ':compileJava' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to <https://docs.gradle.org/7.4.2/userguide/validation_problems.html#implicit_dependency> for more details about this problem.
Ps: I also pushed in case you want to try this yourselves

I don’t immediately see where you configure the sources jar at all.

But consider adding
```java {
    withSourcesJar()
}```
To the build script. Seems to be working for me:
```$ gw --console plain :lib:assemble 
&gt; Task :lib:generateSources
&gt; Task :lib:compileKotlin UP-TO-DATE
&gt; Task :lib:compileJava NO-SOURCE
&gt; Task :lib:processResources NO-SOURCE
&gt; Task :lib:classes UP-TO-DATE
&gt; Task :lib:inspectClassesForKotlinIC UP-TO-DATE
&gt; Task :lib:jar UP-TO-DATE
&gt; Task :lib:sourcesJar
&gt; Task :lib:assemble

BUILD SUCCESSFUL in 1s```

(Btw, I see you use an RC version of Gradle’s plugin-publish. A stable release `1.0.0` has landed recently)
<https://plugins.gradle.org/plugin/com.gradle.plugin-publish>

thanks for the heads up, I just updated to it
however this
```java {
    withSourcesJar()
}```
didn't solve yet the warning about `sourcesJar`
I'm still puzzled why I get the warning about it but if the moment I try to configure it (`getByName("sourcesJar") { .. }` ) then I have the following error:
&gt; Task with name 'sourcesJar' not found in root project 'gradle-catalog'.

so Alex, to sum up, you don't get the warning
I cant understand how is that possible

to sum up, I fixed with  (it's a mp project)
```val generateCode by registering(GenerateCode::class)
kotlin.sourceSets.commonMain { kotlin.srcDir(generateCode.get().outputs.files) }```


Ah, that won't work I guess, as the framework compileJava task is also not triggered when this JAR (snapshot) is updated, so the input change isn't detected anyway.

I ran a build scan and the theme JAR is in the dependency list for the framework compileJava task, so I guess the question is why doesn't Gradle detect that a new snapshot is available and rerun the compilation?

Hmmm... I thought the gradle cache might be the issue so I tried to disable it, but this doesn't seem to have any effect:
```configurations.all {
  resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
}```

Hard to guess without seeing the build. Can you maybe provide an MCVE?

I am getting below error in dependency track pipeline stage -

```Unable to resolve POM for <http://com.XXXXX.em.am:common-api:6.1.4-rc1|com.XXXXX.em.am:common-api:6.1.4-rc1>: org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$ArtifactResolveException: Could not resolve all files for configuration ':detachedConfiguration1'.```


Please don't cross-post to multiple channels, that wastes the time of anyone reading the message multiple times and splits discussions. Pick one appropriate channel according to name and subject and at most post a link in other channels if you really feel you need more attention.

Please do not split topics across several threads.
This makes following the conversation in the threads view very hard as the context of the other messages is missing.
If you have additional information either edit the original message or post to its thread.

Regarding the problem, hard to tell anything with almost no information. You need to at least provide the `--stacktrace`.

Hi..Missed your ping..I pinged dependency-mgt channel...I am new to this group..just understanding the flow of this community.

Perhaps something like this (Kotlin, adjust logic as appropriate):
```    private fun Project.configureRepoPublishing() {
        // only enable publishing tasks for certain repos
        tasks.withType&lt;PublishToMavenRepository&gt;().configureEach {
            onlyIf(
                providers.ciBuild().map {
                    when {
                        it -&gt; when {
                            isSnapshotVersion() -&gt; repository.isSnapshotRepo()
                            else -&gt; repository.isReleaseRepo()
                        }
                        else -&gt; repository.isLocalRepo()
                    }
                }
            )
        }
    }```

Yup, doing something similar right now. However this can be misleading to a user? If someone were to try publishing a snapshot to a release repo. The build would be successful but the publishing task would be skipped.

perhaps, though most times publishing is handled by CI builds, `publish`task handles all that are available to publish.  If user interaction is a concern you could add a doFirst to disabled tasks to throw an exception.

mmm.  perhaps not, if the tasks are disabled they won’t execute doFirst.

That's fair. This would be handled at CI and I would not expect a user to be calling this manually.

For some reason I assumed that this feature would exist :sweat_smile: . It makes sense to be able to disable tasks which are invalid in a particular project.

the feature does exist, in a general sense, via `onlyIf` or `enabled` on any given task.

Or `doFirst` if you want a failure instead.

Thanks! These two approaches would help.  I also wanted to ask about what would be an idiomatic gradle way of doing this?
If I wanted to not expose certain functionality to gradle users and hence want to disable certain combination of tasks based on requirements, is that a valid usecase vs does Gradle recommend an alternative way of dealing this kind of requirement.

I ask this because I've not really come across a plugin that tells me certain tasks are not allowed or disabled etc. A possible solution could be to prevent configuration of such tasks. but that can only happen if the plugin source is under my control.

The idiomatic way would probably be to not add the task if possible, or otherwise to disable it if you don't need lazy logic, or to use `onlyIf` if you need delayed logic.

The extension will only be present _if_ there's a catalog. So my guess is that there's none.

it seems that the extension is not available yet in build scripts that apply my custom plugin in a setting like
```configure(subprojects - project('elasticsearch-log4j')) {
  /*
   * All subprojects are java projects using Elasticsearch's standard build
   * tools.
   */
  apply plugin: 'elasticsearch.build'
}```

I know its not the best approach and I'm about to fix that, but thats how it is at the moment and the dynamics of how this extension is created does not work with this way of configure things

the `VersionCatalogsExtension` exposes a _realized_ catalog

in settings you have access to the _builder_ API

(settings plugins can contribute catalogs, or mutate existing catalogs, so the "realized" version is not yet ready)

I just want to consume an existing catalogue I have defined in my settings file

then it should be visible :thinking_face:

that ugly workaround on defering acccessing version catalogue extension actually works:

```var checkstyleDependencyProvider = project.provider(
                () -&gt; project.getExtensions().getByType(VersionCatalogsExtension.class).named("buildLibs").findLibrary("checkstyle").get().get()
        );
        dependencies.addProvider("checkstyle", checkstyleDependencyProvider);```
:face_vomiting:

this would imply your plugin is applied _before_ the extension is added. I'm not sure how you managed to do that :smile:

can you defer the application of your plugin somehow?

maybe. I will try to reproduce that in a small example project first

I'd rather not do that defering :slightly_smiling_face:

do you recall when and where that extension is added?

I recall it was complicated, and if I recall properly, it's once settings are evaluated

ah no, that's for the catalog creation, for the extension itself... I don't remember.

I have a closer look and try creating a reproducible example to raise a ticket :slightly_smiling_face:

this should be quite early, because catalogs can be used in the plugins block

I think with my sample configuration snippet above of configuring subprojects this breaks that

<https://github.com/gradle/gradle/blob/ca296b3c0ddcf8006061e510f3a6b21a625d5b67/subprojects/dependency-management/src/main/java/org/gradle/api/internal/catalog/DefaultDependenciesAccessors.java#L246>

Are you sure you tried to get it from the correct extensions?
Most time I have seen that extension not be present was because someone just used unqlified `extensions` and thus tried to get it from a task, instead of from the project.

yeah that was one thought too but in my example its explicit. I'm just writing the bug report. and the minimum example snippet that shows the problem is:

```// this works!
def versionCatalogRoot = extensions.getByType(VersionCatalogsExtension).named("buildLibs")
println(versionCatalogRoot.findLibrary("checkstyle").get().get())

subprojects {
    // this throws "Extension of type 'VersionCatalogsExtension' does not exist."
    def versionCatalog = extensions.getByType(VersionCatalogsExtension).named("buildLibs")
    println(versionCatalog.findLibrary("checkstyle").get())
}```


yeah thats what I will do I think to unblock me. Will create a ticket anyhow

subprojects/allprojects is always full of surprises... that said, I still have to find a replacement for when you use an init script which needs to interact with arbitrary projects

yeah I'm in the process of moving away from them but it takes time :slightly_smiling_face:

just getting our codebase to configuration-cache compliant is a task for months (/ or years) :P

don't tell me about this. Micronaut is full of tricks which would probably explode with the CC.

yeah our integration test infrastructure for managing elasticsearch nodes in any possible way is full of ~garbage~ `magic`

to close the loop... <https://github.com/gradle/gradle/issues/21191> now I need to rewrite my build scripts in the mean time

The error indicates that the property you are trying to reach is only looking in the `Credential` object.
Try prefixing it with `settings`.

Note that Gradle has a gap in documentation on this topic, which is addressed for the future 7.6 release.
See <https://docs.gradle.org/nightly/userguide/build_environment.html> for details and different notations.

Is there any reason to not doing directly instead of loading the Properties manually?
```val prop = target.getProperty("your prop")```

In the end I went with:
```sync.from(extension.getFileProperty());```
followed by:
```pushTask.getFileInput().fileProvider(syncTask.map(s -&gt; {
           ConfigurableFileTree files = project.fileTree(s.getDestinationDir());
           if (files.isEmpty()) {
             return null;
           } else {
             return files.getSingleFile();
           }
         }));```
Then push task then has the following in it’s constructor:
```onlyIf(t -&gt; getFileInput().map(f -&gt; f.getAsFile().exists()).getOrElse(false));```

When settings plugin is running it's too late to set pluginManagement.repositories since it was already used to produce classpath to run settings script and settings plugins.
You can move required logic to init script (one of possible variants is to create custom gradle distribution with an init script bundled). 
Adding repositories for project plugins should work though.

The question is, where do you get your settings plugin from?
If the settings plugin is in your artifactory, then you need the `pluginManagement { repositories { ... } }` already for finding your custom settings plugin. I think a custom settings plugin could indeed add additional `pluginManagement` repositories if they are for project plugins, not for settings plugins, or maybe for settings plugins applied later than that one eventually, not sure about that. But what would then still not work is, that the `gradlePluginPortal()` is not added to the plugin management repositories as for that the adding in a settings plugin is too late.

It certainly works for project plugins. In my settings plugin `ws.gross.private-repo` I add internal nexus (with content filters), `mavenCentral` and `gradlePluginPortal` to the pluginManagement repositories and use plugins from the private nexus later.

But I created and published that plugin to the Plugin Portal to avoid setting private repository in each build's pluginManagement or using init script since there's a lot of projects where I don't need my internal repositories.

The API to properly fix this in Gradle is recent. I think we are looking at fixing this for our F release.

<@UFM5QBT4H> F release?  Would this be a fix in android studio?

There is partly a fix in studio and one in AGP. It's easier to go with letters so I said F, and also we're not sure yet the version coming after AGP 7.4 (could be 8.0 or 7.5)

Gotcha.  Thanks <@UFM5QBT4H>  In the mean time we’ll live with it i guess.

You could register another test task with different system property and select tests to run both in it and original test task. If you use junit5 you certainly could select tests by tags.

Another way would be to just use System.setProperty in tests themselves and reset it to original value after.

Unless you run tests in parallel, then you also need to properly lock accordingly. With Spock you could simply acquire the global lock to run the test isolated using `@Isolated` when running with parallel enabled and `@RestoreSystemProperties` or how it is called to automatically restore the properties after the test.

&gt; You could register another test task with different system property and select tests to run both in it and original test task. If you use junit5 you certainly could select tests by tags.
<@UJUMPU407> <@URQ797WRW>: Thanks for your inputs.

Creating a new task seems to be easy option. I am thinking of creating a new task (type Test) something like below assuming it will launch tests in separate JVM.
```task mySpecialTests(type: Test) {
    include 'com/somepackage/**'
    systemProperty 'some.prop', 'value'
    jvmArgs '-XX:MaxPermSize=256m' --&gt; Does it forces gradle to use separate JVM ?
}```
BTW, does gradle launch `Test` type tasks in separate jvm, <https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html|gradle doc> doesn’t say about it.

Yes and no. It usually uses a separate test worker process that can be reused for different test tasks, but it should also handle the system properties according to your task setup.

You probably have to get the script as resource from the class path and then copy it to a temporary location

yeah, but I tried things like
```ClassLoader.getSystemClassLoader().getResource
ClassLoader.getSystemResource
this.javaClass.classLoader.getResource```
and I always get null. so I'm at a step before copying, can't even reference the file in resources

Maybe your url is not correct. It for example makes a difference whether you have a leading slash or not in combination of whether you use class or classloader.

Docs clearly state that tests are `always` run in separate JVMs

Which can be reused between test tasks, can't they? But you should normally not need to care

I could separate it in a previous task in the root build dir, and getting it from there in the subproject task, but this implies calling both tasks separately because the subproject task one can't depend on the root task one

If that plugin doesn't add variant but writes file as task output you could do it yourself via consumable configuration in root project, assigning it some custom attributes plus adding variant based on the configuration and than consume it in subproject using resolvable configuration with same attributes and `project(":")` dependency. See <https://docs.gradle.org/current/userguide/cross_project_publications.html|https://docs.gradle.org/current/userguide/cross_project_publications.html>

Looks like it is not a task, it is just a method on its extension `ChangelogPluginExtension.get(version: String)`

Thank you, I will try :slightly_smiling_face:

Yeah, it should work. Just did something similar to fetch and write Kubernetes CRDs for Traefik (as additional variant) with another task to generate java code for them and standard java-library for primary variant. 

Just love when a task falls in with gradle's modelling, makes quite easy to express what needs to be done in gradle dsl. Also become huge fan of implicit dependencies recently, it simplifies consuming a result of one task in another in concise and maintainable code

The task should only need to output a string, but I guess I need to generate a Jar, right?

```// this can't work if the task output is an `String`
artifacts {
    add("instrumentedJars", someTask.outputFile) {
        builtBy(someTask)
    }
}```

I hope JvmEcosystemUtilities and JvmModellingServices become public sooner than later

Just create task with `@get:OutputFile abstract val out: RegularFileProperty` parameter, write the txt/xml file in its task action, create separate configuration (with `isCanBeResolved=false` and `isCanBeConsumed=true` plus `attributes` block to define some attributes to differentiate from other variants)

Then use `components["main"] as AdhocComponentWithVariants` to add variant from your configuration

Forgot to mention, you'll need to add the output file to the configuration. I'm not sure but think that `outgoingCofiguration.from(tasks.named("writeTask"))` should work

thank you for the detailed response :slightly_smiling_face:

I was trying with artifacts and I didn't get the deprecated mention :thinking_face:

is there any place to check the new docs?

Currently afk, so all off the top of my head

Not sure that it's in current docs but heard it in this slack when cross project publication was mentioned

I still used it to attach artifact somewhere myself so it should work. Mb it as not recommended way and not deprecated per se

the outgoing plus artifact (image I shared) should work as top level artifacts? or it is a totally different thing

That means that Configuration doesn't extend ConfigurableFileCollection(

In my case something like this works:
```// in producer project, fetchCrd has single OutputDirectory property
val fetchCrds by tasks.registering(FetchCrdTask::class) {
 // ...
}

val crds by configurations.creating {
  isCanBeConsumed = true
  isCanBeResolved = false
  attributes {
    attribute(Category.CATEGORY_ATTRIBUTE, objects.named(Category.DOCUMENTATION))
    attribute(DocsType.DOCS_TYPE_ATTRIBUTE, objects.named("CRD"))
  }
  outgoing.artifact(fetchCrds)
}

// in consumer project
val crds by configurations.creating {
  isCanBeConsumed = false
  isCanBeResolved = true
  attributes {
    attribute(Category.CATEGORY_ATTRIBUTE, objects.named(Category.DOCUMENTATION))
    attribute(DocsType.DOCS_TYPE_ATTRIBUTE, objects.named("CRD"))
  }
}

tasks.register&lt;Copy&gt;("consumeCrds") {
  from(crds)
  into(layout.buildDirectory.dir("kubernetes/crds"))
}```

`outgoingVariants` task produces something like

```&gt; Task :traefik-crd:outgoingVariants
--------------------------------------------------
Variant crds
--------------------------------------------------
Capabilities
    - xxxxxx.operator:traefik-crd:0.1.0-dev.3.uncommitted+c65529a (default capability)
Attributes
    - org.gradle.category = documentation
    - org.gradle.docstype = CRD

Artifacts
    - build/kubernetes/crds```

`dependencyInsight` (w/ Gradle 7.5-rc-4) show that it was matched on these attributes:
```&gt; Task :xxxxxx-operator:dependencyInsight
project :traefik-crd
  Variant crds:
    | Attribute Name      | Provided      | Requested     |
    |---------------------|---------------|---------------|
    | org.gradle.category | documentation | documentation |
    | org.gradle.docstype | CRD           | CRD           |

project :traefik-crd
\--- crds```

sorry for the typos, it's around 2am for me

Almost same here, don't worry :slightly_smiling_face:

But it is necessary to add it as dependecy, right?

I am executing the copy task, but it does nothing

I guess I've mixed `Project#artifacts` with `archives`. It internally works with same `Configuration#artifacts` as does `Configuration#outgoing#artifact`

Yeah, dependency is what really binds it together

I get it working, really thank you :smile:

If you use variant aware publishing (with matching attributes on both sides) you just use `myConfiguration(project(":module"))` and it works. Same if you publish to nexus with gradle metadata and then consume it by GAV coords

One thing to be aware: if you publish root project to nexus/artifactory you'll get warnings. Either skip this this variant publication with something like `(components["java"] as AdhocComponentWithVariants).withVariantsFromConfiguration(crds) { skip() }`, turn warning about maven incompatibility off or just ignore it ,)

Same thing that you'll get with java/java-library + java-test-fixtures in one project

good to know, but I generally don't use the root module as something which can have sources or something so, just to configure "generic" plugins like ChangelogPlugin, Nexus plugin and so on.

Even if I have only one module I use a subproject too

the subproject which is going to consume that configuration can be published, the warning can be there too?

sadly I haven't played with java test fixtures yet, Kotlin doesn't support them in Android/KMP projects :cry:

I am simulating them in a poor way by having a submodule which that name so when they are supported I can just remove the build.gradle.kts in that module :joy:

aah, I used them only with java/kotlin-jvm/groovy(spock) since I don't do android/kmp projects

I guess you could model something similar if need arise but it could be easier to create another subproject for now for fixtures/common test code

I usually create custom source sets for codegen, Gradle's ad-hoc tasks for that is one of the major selling points for me opposing Apache Maven mojos

Yeah, I create them in build/generated like kapt or other plugins do

Please don't cross post, it creates unnecessary noise.

I am passing it as string, but a bit ugly to need to use `?.toBoolean`

Invert the logic and name to `--not-something`

I feel it is related to some dependencies version, but not totally sure.

Please do not split topics across several threads.
This makes following the conversation in the threads view very hard as the context of the other messages is missing.
If you have additional information either edit the original message or post to its thread.

Regarding the problem, the little excerpt you shows, clearly says there is a compiler error, so most probably your code is simply invalid. Scroll up as advised to see the actual compile errors. :slightly_smiling_face:

Perhaps a `doFirst` block in processResources?  Hard to say without understanding what you’re trying to accomplish.

I'm currently replacing tokens like `@test@` into the source files and the resource files, everything works with the source files. The files are processed and saved to `build/source/resources/` but I don't know how to make it so the ProcessReaources task use as input said folder instead of the `src/main/resources` folder

You should probably use `filter` or `expand` instead.

yes, exactly.  As ProcessResources is a Copy task, using a CopySpec, you can use filter or expand to adjust files as they are copied.

So there is no way like AbstractCompile to set the source directory? And if I were to use the filter method, how could I do it? (Sorry but I'm new into the gradle plugin api xD)

no need to change the source directory.  if the goal is solely to replace tokens, that can be done as processResources is copying files.  Review the expand/filter options on `CopySpec` for details on that.

Ok, I'll check it out and share my findings when I'm done ;)

Ok, since the base (using the custom source dir) was already written (for other compile tasks such as kotlin, java, etc) I needed to use the custom source directory. I first included using `ProcessResources#from(Project#files(File))` I’ve added the custom source dir, and then using `ProcessResources#eachFile`  I’ve filtered and excluded the files that were not included in the custom source dir (since the tokens are replaced on every resource) It may not be the best approach, but it works :p

Please provide the `--scan` if possible or at least the `--stacktrace`

Please don't post in multiple channels. cc <@U03GV74JEH3>

can you show the relevant part of your build script? how are you declaring the plugin dependency?

```plugins {
    id 'java'
    id 'idea'
    id 'com.gorylenko.gradle-git-properties' version '2.2.3' // note, upgrade when moving to new gradle
}```


it seems like a more general plugin issue, since when I comment the gorylenko plugin it fails in similar manner with other plugins for example:
"Plugin [id: 'org.flywaydb.flyway', version: '5.2.4'] was not found in any of the following sources:"

does it give you more information if you run with `--stacktrace` ? ( or perhaps `--debug` ) It’s been ages since I worked with gradle 4.x, so :shrug:

2022-07-12 12:58:56,045 [1214314]   INFO - #o.j.p.g.s.p.GradleProjectResolver - Gradle project resolve error
org.gradle.tooling.BuildException: Could not run phased build action using connection to Gradle distribution '<https://services.gradle.org/distributions/gradle-4.10.3-all.zip>'.
	at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:51)
	at org.gradle.tooling.internal.consumer.ExceptionTransformer.transform(ExceptionTransformer.java:29)
	at org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:43)
	at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:69)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.gradle.internal.exceptions.LocationAwareException: Build file 'C:\git\hem-app-monolith\core\build.gradle' line: 4
Plugin [id: 'com.gorylenko.gradle-git-properties', version: '2.2.3'] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (could not resolve plugin artifact 'com.gorylenko.gradle-git-properties:com.gorylenko.gradle-git-properties.gradle.plugin:2.2.3')
  Searched in the following repositories:
    Gradle Central Plugin Repository
	at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.resolveToFoundResult(DefaultPluginRequestApplicator.java:263)
	at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator.access$100(DefaultPluginRequestApplicator.java:63)
	at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator$1.transform(DefaultPluginRequestApplicator.java:91)
	at org.gradle.plugin.use.internal.DefaultPluginRequestApplicator$1.transform(DefaultPluginRequestApplicator.java:88)
	at org.gradle.util.CollectionUtils.collect(CollectionUtils.java:204)
	at org.gradle.util.CollectionUtils.collect(CollectionUtils.java:199)

Problem solved with different Java SDK version.

there is a `ignoreExitValue` property on `Exec` and `JavaExec` tasks (such as `run`). but I think it won't be passed on to the caller

if you're using the `application` plugin, try `./gradlew :myscript:install &amp;&amp; myscript/build/install/myscript/bin/myscript "$@"` - this runs the program outside of Gradle

Thanks, I tried both suggestions.
Adding the following lines to my gradle.build.kts did not change the error output:
```tasks.withType&lt;Exec&gt;().forEach {
    it.isIgnoreExitValue = true
}```
Adjusting the launcher script did the trick:
```# shellcheck disable=SC2086
# shellcheck disable=SC2048
./gradlew :myscrip:install -q &amp;&amp; ./build/install/myscript/bin/myscript $*```
Looking at these options, I think the launcher script adjustment makes a lot of sense. Just for reference, did I make a mistake in the gradle.build.kts adjustment?

```tasks.run {
    isIgnoreExitValue = true
}```
1. `run` is `JavaExec`, not `Exec`
2. use `configureEach` to maintain lazy configuration… but better yet, only configure the specific task
but the script approach is probably better for you anyway, because Gradle will still exit with success when the process exits with failure with `ignoreExitValue`, so the caller won't see it

You should use both. There are plans to embed wrapper validation in `gradle-build-action` in the future.

Fwiw <https://github.com/gradle/gradle-build-action/issues/151>

reposting for a colleague not in this slack. This is about *gradle-profiler*

if I were to have a benchmark scenario like this:
```clean_build_cash_internal_debug {
    title = "Clean Build"
    tasks = [" app:assembleInternalDebug"]
    daemon = warm
    clear-configuration-cache-state-before = SCENARIO
    clear-build-cache-before = SCENARIO
    clear-project-cache-before = SCENARIO
}```
Does `SCENARIO` mean that these will be run once before the benchmarking kicks off? and `BUILD` would mean before each iteration without adding to the duration of that iteration ? This isn't super clear: <https://github.com/gradle/gradle-profiler#profiling-incremental-builds>

I think what those values mean (SCENARIO vs BUILD) is that the former will run before the scenario begins and the latter will run before each iteration. There's also `CLEANUP`, and I'm not sure if that's after the scenario is finished or after each build. I also assume that all of these `clear...` options do _not_ impact the measured duration of the benchmarked build, but I'm not 100% sure.

I think this is because the `includeBuild`  is a rootProject and not a `project` for the settings delegate. But I cannot figure out how to define the projectDir for the `plugin-A`  here .

looks like I need to define the path as a part of the includeBuild itself.
something like `includeBuild("plugins/plugin-A")`

The syntax for name/path of `include()` and `includeBuild()` is unfortunately not the same and I think that is confusing you here.

For `includeBuild` you can just do `includeBuild("plugins/plugin-A")` . Here the parameter is the file path to the location of the build and nothing else.

The *name* of the included build is determined by the name defined in that project. In your case, you could change it by setting `rootProject.name` in `plugin-A/settings.gradle(.kts)`

There is this suggestion to adjust `include()` , so that you may write `include('sample/app')` and not have to do it in “two steps”. Then it would be in a way a bit closer to what `includeBuild()` does.
<https://github.com/gradle/gradle/issues/14561>

Yup, a similar dsl would be useful :slightly_smiling_face: . :star: ing that issue.

I took a look at
• Source dependencies: <https://blog.gradle.org/introducing-source-dependencies>
• IncludeGit gradle plugin: <https://melix.github.io/includegit-gradle-plugin/latest/index.html>
But I couldn’t quite figure out if this completely replaces the need to publish artifacts or not and then how to handle versioning