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

Gradle Community

About 5 minutes ago Chris Lambertus (Apache Infra team) who reported the issue to Sonatype forwarded this message:

&gt; Thanks for bringing this to our attention.  We performed a round of DNS record cleanup today and unfortunately this record was mistakenly removed.  We've rolled back the changes, though it may take a few minutes for the changes to propagate.  I'll resolve this issue once I have confirmation the name resolution is working again.
So as soon as DNS propagates to your systems it should be available again

I have:
```    
tasks.withType&lt;Test&gt;().configureEach {
     modularity.inferModulePath.set(false)
}```

how can I force it to use good old classpath for tests?

:face_with_raised_eyebrow:  This sounds like a bug. Do the tests themselves have a "module-info.java" in the test sources?

for context I can't run my tests with module path, because they fail with Spock, which is not module compatible

IIRC, test would only run like that if a "module-info.class" is in `testClassesDirs`

Maybe such a file ends up there from somewhere else?

I don't think so, the issue disappears if I remove my `module-info.java` from the main sources

also checked and testClassesDir doesn't have the main sources (as expected)

I am surprised by this behavior. Usually it's the other way around. It's difficult to get the tests to run as module, if they don't have "module-info" (and only the main sources have). Like here: <https://github.com/gradle/gradle/issues/22506#issuecomment-1301266392>

I am also surprised, and I must say that's quite annoying :smile:

Have you tried with a 7.x Gradle version? There were these changes with the test classpath setup....

I have no other idea, than debugging into the code that makes the decision to use the "module path" and see what causes this behavior there.

Do you effectively have split package with main sources? And is does it work with different source set than `test`?

So tests are in different package then, ok

the tests are in the same package as the main sources though

but it shouldn't matter: I don't want to run tests with `module-path`

somehow Gradle absolutely wants to do that

yeah, it looks like a bug if you turn of jpms for `Test` task

if you didn't try it earlier, try to move tests to other source set, since `test` might be "special"

if it still runs it with module path instead of normal class path and you don't have `main` in deps of course

if you have `main` in immediate deps it will likely resolve as classes dir and you effectively have module-info visible

I'm starting to think it's the org.openjfx.javafxplugin plugin causing this, but not sure yet

Yes. That applies "org.javamodularity.moduleplugin.ModuleSystemPlugin" under the hood

Not familiar with it, does it call `modularity.infetModulePath.set`? If so you could try to call `set` in `afterEvaluate` despite code smell

That one does a lot of moving things around. It's the "old" plugin that does not built on Gradle's native module system support.
If you need to keep it, you probably need to configure that plugin.

For your convienence :wink:
<https://github.com/java9-modularity/gradle-modules-plugin/tree/master#fall-back-to-classpath-mode>

```test {
    moduleOptions {
        runOnClasspath = true
    }
}```

yup found that too, but configuration doesn't work with Kotln DSL, the extension type isn't found...

2 will be evaluated very late and only fail then if the task really does not exist.
1 fails instantly if the task is not available already.

That also means that for 1 you require that "something" is evaluated before the project you have that in and also that it requires that it also is evaluated always if that project is evaluated.

So 2 might be a bit safer, but actually, practically any explicit "dependsOn" that does not have a lifecycle task on the left-hand side is a code smell and should be avoided. So unless `taskA` is a lifecycle task, better wire inputs and outputs together and get implicit task dependencies running properly. See <https://docs.gradle.org/current/userguide/cross_project_publications.html> for proper cross-project publication ways.

Thanks for the input <@URQ797WRW>! Somewhat related, what if project `:something` is not necessarily available under certain conditions (e.g., project changing configuration from `taskA` is part of an included build that `:something` is not)? Is it possible to _conditionally_ configure `taskA` only if `:something` is present?

Well, yeah, make an `if` that checks whether the project exists.

But tbh, that also sounds like a code smell. :slightly_smiling_face:

Indeed I agree with you! for now, it's workaround solution for a complex setup, but later on, the plan is to get away with unwanted tasks and unnecessary dependencies. In the end I changed the `dependsOn` relation for `mustRunAfter` to see how it works and I might go with it for now.

I don't think it changes anything in that regard

You could switch to `compileOnly` for spring boot plugin in `buildSrc/build.gradle.kts` and still try to apply it with `plugins { id("org.springframework.boot") }` in the convention plugin. It will require to apply relevant spring boot plugin for each relevant project but you shouldn't have whacky classpath issues that way. Of course, if you configure spring boot plugin from convention plugin (like calling `springBoot { buildInfo() }`) its api should be compatible and it's on you to check if it is.

Also if you don't override some dependencies versions using properties don't apply `io.spring.dependency-management`, just use normal gradle BOM/platform support.

Also, I'd recommend to avoid `apply(plugin = "..")` and use `plugins { .. }` instead. You'll likely have to do same `compileOnly` trick for kotlin plugin (and same for kotlin spring subplugin), especially if you kotlin plugin version differs from `embeddedKotlinVersion`)

Another way to go is to have several convention plugins for different spring boot versions in different subprojects, not sure if it would work with `buildSrc` but it works quite fine with included builds

From what you say, it seems to me that it is far from ideal to handle this within buildSrc.
Furthermore, `have several convention plugins for different spring boot versions in different subprojects,` ; as far as I understand this will not be possible because that would mean to have multiple versions of the same plugin into `buildSrc/build.gradle.kts` .

I’ll give a try with included build :+1:

I'm not sure if it's possible with buildSrc because of its special place in the build classpath. But with included build you could easily have `build-logic/boot26/build.gradle.kts` and `build-logic/boot27/build.gradle.kts`.
But maybe you could use the same plugin like 2.7.x and just vary platform version between projects that use different spring boot version

I'd try later first since boot plugin changes could be rather minor

Following the <https://docs.gradle.org/current/samples/sample_structuring_software_projects.html|Gradle sample> with composite builds, they seem to have:
```platforms/plugins-platform define api version constraints for kotlin and spring plugins
build-logic/kotlin-library 
build-logic/spring-application```
I should be able to achieve something similar:
```// platforms/plugins-platform/build.gradle.kts
dependencies {
    constraints {
        api("org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin:1.8.10")
        api("org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.10")
        api("org.jetbrains.kotlin:kotlin-allopen:1.8.10")
    }
}

// build-logic/spring-boot-application/src/main/kotlin/com.example.spring-boot-application.gradle.kts
// just define common implementation to be used
dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation("org.springframework.boot:spring-boot-starter-jooq")
}

// applications/some-app-on-boot26/build.gradle.kts
plugins {
    id("com.example.spring-boot-application")
    id("org.springframework.boot") version "2.7.8"
}```
Next step is understanding difference between spring-dependency-management plugin and spring bom (you talked about it earlier).
Good start seems to read <https://nexocode.com/blog/posts/spring-dependencies-in-gradle/|this blogpost>

Bonus question, do you have any experience with managing gradle dependencies with toml file?
My first concerns are:
• IntelliJ IDEA support
• Github dependabot support
• any caveat, pros and cons vs using pure gradle

&gt; Next step is understanding difference between spring-dependency-management plugin and spring bom (you talked about it earlier).
Spring dependency management plugin is a plugin that could apply bom using legacy mechanisms for old gradle versions before native bom/platform support. So instead of

```dependencyManagement {
  imports { 
    mavenBom(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
  }
}```
you just use

```dependencies {
  implementation(platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES))
}```
If you need to override some dependency version you could use usual dependency constraints.

&gt; Bonus question, do you have any experience with managing gradle dependencies with toml file?
If you mean version catalog in toml format than yes. I use it quite a lot. IDEA support still not very great:
• after adding/removing alias to the catalog you'll need to reload/reimport to have completion for updated aliases
• click/ctrl+b on `libs.some.thing` will lead you to generated code and not the catalog itself
I don't remember if dependabot tries to suggest catalog modifications but that's useless since real versions are determined after dependency resolution, so versions written in build files and/or catalogs could differ from real ones. There were plugins to upload dependency resolution results for dependabot to analyze but I haven't tried them yet.

What do you mean by "vs using pure gradle" idk, there's a lot of methods people use to manage deps

I was just wondering why people use toml, but I guess I need to dive a bit in it.
FYI, toml seems to be <https://github.com/dependabot/dependabot-core/issues/3121|supported by dependabot>. I understand that static analysis of this file does not resolve dependencies. (I guess dependabot execute static analysis). Nevertheless, with Gradle highest-version resolution (&lt;&gt; Maven nearest to root resolution) ; it seems to be a good start on my side.

Anyway, thank you for your help, I’ve learned a lot! Appreciated :slightly_smiling_face:

Ohh, they just merged support for catalogs a week ago, great. Thanks for the info :tada:

I have looked into this (<https://github.com/gradle-nexus/publish-plugin/issues/96>) issue and although the messages are the same, it doesn't appear to be a similar problem to the one I am currently having. Any help will greatly be appreciated

I have opened an issue here as well <https://github.com/gradle-nexus/publish-plugin/issues/217>

There were some quirks with Sonatype services and also Maven Central. Maybe that is the cause? Just guessing though. I know that last friday a publish using that plugin was successful.

If I get it directly via `extension.getByType(PlayPublisherExtension)`, `register` method doesn't exist

It's a `NamedDomainObjectContainer&lt;PlayPublisherExtension&gt;`, you'll have to get it by name.
See <https://github.com/Triple-T/gradle-play-publisher/blob/77b069708cfd1bedfce5424af2c4a92cc9439763/testapp/build.gradle.kts#L97> for an example.

Wops, I didn't know I can do `configure&lt;NamedDomainObjectContainer&lt;PlayPublisherExtension&gt;&gt;`, thank you!

That's a `kotlin-dsl` extension for `configure(TypeOf,Action)`: <https://docs.gradle.org/current/javadoc/org/gradle/api/plugins/ExtensionContainer.html#configure-org.gradle.api.reflect.TypeOf-org.gradle.api.Action-|https://docs.gradle.org/current/javadoc/org/gradle/api/plugins/ExtensionContainer.html#configure-org.gradle.api.refl[…]TypeOf-org.gradle.api.Action->

I am even trying to force a specific version of Kotlin Serialization, but it still fails

```plugins {
    `java-gradle-plugin`
    alias(libs.plugins.kotlin.jvm) // 1.7.10
    alias(libs.plugins.kotlin.serialization) // 1.7.10
}
dependencies {
    implementation(libs.serialization.core.get().module.toString()) {
        version {
            strictly(libs.versions.serialization.get()) // 1.4.1
        }
    }
    implementation(libs.serialization.json.get().module.toString()) {
        version {
            strictly(libs.versions.serialization.get()) // 1.4.1
        }
    }
}```

Looks like this fixes the issue:

```configurations.all {
    resolutionStrategy.sortArtifacts(ResolutionStrategy.SortOrder.DEPENDENCY_FIRST)
}```
So I guess some configuration is not using my strict version as it is only on implementation?

Hi there, wonder if anyone knows what's up with this error in gradle 8.1

<https://discuss.gradle.org/t/gradle-8-x-complains-about-default-configuration-not-resolvable-how-to-solve/45418>

To understand what's going on I usually compare the dependency graphs of both versions. When you run with "--scan" you can check through the dependencies in the build scan. Gradle Enterprise has a very nice comaparision feature for that but unfortunately that's not available in the public Build Scan version.

What I do as alternative is running the _dependencies_ task and write that to a file and then do a comparison of the text files (IDEA is doing this very well). For example:
```./gradlew :app:dependencies -q --configuration=runtimeCLasspath &gt; gradle7-deps.txt```

In general, if you move away from "compile", I can recommend using the dependency analysis plugin:
<https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin>

I give an overview of that here: <https://youtu.be/Lipf5piizZc>

Reposting with *"Also send to # community-support "* option checked. Deleted my earlier duplicate message in the thread.

I am trying to upgrade a multimodule project (with several hundred subprojects) from *Gradle 6.6 to 7.6.*
I tried taking help from IntelliJ IDEA's inspection feature to find out deprecated api/configuration usages. But it seems IDEA could only recognize compile -&gt; implementation migration.


Once I applied IDEA's suggestion, all `compile` configurations got changed to `implementation`. But I found no usage of api configuration whatsoever. As a result of this my build keeps failing everytime unless I change all transitive dependencies' declarations to use api configuration. Initialy I did try to look out for any such plugins but couldn't find one. Literally no mention of this plugin in the search result when I queried for "plugin to convert from implementation to api, gradle". I then went about doing it by hand but soon realised this wasn't a feasible option give the size of the project that I am dealing with. Luckily enough, I thought of searching in this slack channel and came acrosss this thread.

I tried to use this plugin and could see its tasks listed upon running `gradlew tasks`. But since all my projects are having only implementation configurations, whenever I try to run `projectHealth` or `buildHealth` task the build fails everytime complaining about *"package xyz not found"* as its unable to resolve the classes because they happen to be coming from transitive dependencies. This is where I am confused as to how then will the plugin be able to identify the issues with transitive depdencies that are wrongly declared as implementation, if my build keeps failing with *"package not found found error".*

I am now not sure how to best use this plugin to help me with my upgrade.
Any help or guidance is greatly apreciated.

Declare them all as `api` then use the plugin recommended above by Jendrik, it will tell you which ones you can put back to `implementation`

Thank you so much <@UDC9Q9RD0>. I'll defintely give it a try. Will share the status.

```➜  ir-csa git:(CLOUD-3831) ✗ ./gradlew buildHealth -Dorg.gradle.java.home=/Users/anwarparker/Library/Java/JavaVirtualMachines/corretto-11.0.15/Contents/Home 
Starting a Gradle Daemon, 1 stopped Daemon could not be reused, use --status for details
Configuration on demand is an incubating feature.

&gt; Configure project :
Parallel forks:6

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'ir-csa'.
&gt; Failed to apply plugin 'com.autonomousapps.dependency-analysis'.
   &gt; Cannot run Project.afterEvaluate(Action) when the project is already evaluated.

* Try:
&gt; Run with --stacktrace option to get the stack trace.
&gt; Run with --info or --debug option to get more log output.
&gt; Run with --scan to get full insights.

* Get more help at <https://help.gradle.org>

BUILD FAILED in 26s```

I managed to get the plugin to work. There were some false recommendations specifically where `Unused dependencies which should be removed` were mentioned. Removing the “unused” dependencies would result in a build failure due to missing packages.

If you can isolate these "false recommendations" into a reproducer that would be great.

I think you are hitting this:
<https://docs.gradle.org/current/userguide/upgrading_version_6.html#configuring_the_layout_of_an_ivy_repository>

Need to change that in the definition of your ivy repo(s)

Thanks Jendrik for the quick response. I have seen the above link already. I don’t think we have any Ivy repositories in Jfrog

Are you sure you are on 4.31.9?
I don't see the closure your stacktrace mentions:

Yeah, here is what I have in `build.gradle`

```plugins {
    id "org.sonarqube" version "2.8"
    id "com.github.davidmc24.gradle.plugin.avro" version "1.3.0"
    id "com.jfrog.artifactory" version "4.31.9"
}```

Well, as I siad, it seems not to be what is used, as the closure does not exist there. :wink:

There were some references where I missed upgrading the plugin version. It’s working fine after fixing them. Thanks <@URQ797WRW>

How do they need to "learn Kotlin" if they only modify "dependencies, includes, excludes etc"? Syntaxwise it should practically be the same. And up to now they have to "learn Groovy". :slightly_smiling_face:

If it's simple enough, then it shouldn't be more "learning Kotlin" than you're currently asking them to "learn Groovy".

Nobody is asking them to “learn Groovy” they already know it. If I migrate now (or in the future) to Kotlin I’ll be asking them to learn Kotlin in addition.

But it is trivial for the use-case you described, isn't it?
They don't need to learn much Kotlin.

Besides that noone forces you to change to Kotlin DSL, it is just promoted more to use it due to its pros by generating it by default and showing it first when opening the userguide. But I don't think Groovy DSL will be dropped "anytime soon" or ever.

I guess I’m trying to understand if the position is either:
1. Kotlin is the future, Groovy is legacy.
2. Kotlin is the statically typed way, Groovy is the dynamically typed way, both are valid, but we prefer static.

My totally uneducated guess is 2.
But I'm just a user like you, so I don't know. :slightly_smiling_face:

Groovy is and will stay supported. 2. it is

you can always do it in bits and pieces. that's the way to do it. sneak it in :wink:
plus honestly...it pretty much looks the same. if i see groovy code i can convert it to kts. there are just some oddities sometimes if you've got multi project builds and convention plugins. but you'd get a lot of those w groovy anyway

one thing i was wondering, if gradle had any plans to make arguments/params discoverable. i suspect this is actually becuase of the non-static limitations of groovy. basically, if i run a task in intellij and start typing "gradle mytask", i would expect it to be able to autocomplete that i want to pass in `gradle mytask -PdoStuff` . the current setup makes these non discoverable. you have to poke around and hope you find it, versus autocomplete telling you the possible options

that would be a _huge_ QOL for me, and i suspect for others...

If `doStuff` is for `myTask` and meant to be supplied on the commandline, make it an `@Option` instead.
Project properties are not "assigned to" something, so you can hardly have some autocompletion unless whoever reads the property would additionally register it with some lookup registry.
The `@Options` are afair also not autocompleted in the IDE, but that could maybe be added.
Not that this topic has anything to do with the current thread. :smile:

@option instead of parameter you mean? i'm unfamiliar with how those params currently get described in plugins
the context i'm thinking of is this: <https://axion-release-plugin.readthedocs.io/en/latest/> ./gradlew markNextVersion -Prelease.version=1.0.0
so, ideally the plugin should switch that to use an @Option .. and then is that with -Drelease. ? was reading the docs on best practices but i thought params were the way to go there

No, not `-D` that would be a system property.

`@Option` are like `gw markNextVersion --version 1.0.0`

You can of course also support both, `@Option` for commandline usage given for a specific task, project property for configuring it in Gradle property files.

Anyway, all I'm saying is, that `@Option` is more likely to be made auto-completable, I guess that is just missing functionality in IntelliJ

i kinda doubt you can do that, because the heap space it's talking about, is done at the jvm launch time. that's just the way the jvm works...so the only way to do it that way i guess would be to fork it into another one, similar to what TestKit does

so..i would say: no

why would you want to do it on a per task basis anyways? that seems like premature optimizing for no reason

Some tasks support forking (e.g. `JavaCompile`) and you can then configure JVM arguments for that task (or to be accurate about `JavaCompile`, for a dedicated daemon process that can be reused between tasks and runs)

interesting, didn't know that about javacompile

<https://docs.gradle.org/current/dsl/org.gradle.api.tasks.compile.CompileOptions.html#org.gradle.api.tasks.compile.CompileOptions:fork>

the error I get is:

```Cannot convert the provided notation to an object of type ConfigurablePublishArtifact: file collection.
The following types/formats are supported:
  - Instances of ConfigurablePublishArtifact.
  - Instances of PublishArtifact.
  - Instances of AbstractArchiveTask, for example jar.
  - Instances of Provider&lt;RegularFile&gt;.
  - Instances of Provider&lt;Directory&gt;.
  - Instances of Provider&lt;File&gt;.
  - Instances of RegularFile.
  - Instances of Directory.
  - Instances of File.
  - Maps with 'file' key```

Should I `Sync` this `FileCollection` into a `Provider&lt;Directory&gt;`?

or should I zip these files into a `sources.jar` and then unzip them on the consumer side?

I'd share the root directory/directories containing the source files. That's what I do for Java files to be used with GWT, but the consumer needs the files to be in their expected package tree structure so sharing directories works better for my usecase anyway.

You can also look how the jacoco report aggregation plugin does it, or actually apply that one for that use-case, as it provides the sources as consumable configuration.

Call `notCompatibleWithConfigurationCache()` on any of the tasks that is going to be executed.

Problem with `notCompatibleWithConfigurationCache()`  is that is it not final, so when I want to put it to the constructor of the task, there is warning, that calling not final method from constructor is not a good idea.

Well, better fix your task to be CC compatible. :smile:

Yes, but some tasks are running just on CI (Teamcity) where there is no cache anyway), so it doesn't make sense to invest time to it.

Or are called so rare, that doesn't make sense to do it in the first phase.

Then either ignore the warning, or override the method and make it final if possible, or call it from outside, for example with a `task.withType&lt;...&gt;().configureEach { ... }`

Hey, <@U04NU3YN79Q>! Take a look at this: <https://docs.gradle.org/current/userguide/init_scripts.html#sec:custom_classpath>

Though you will not be able to reference the `gradleEnterprise` extension like that.

agree.init.gradle.kts.kt

I’ve been using this set up for people to put into their init.d
```if (gradle.getParent() == null) {
  beforeSettings { settings -&gt;
    settings.buildscript.repositories { gradlePluginPortal() }
    settings.buildscript.dependencies.add("classpath", "com.gradle:gradle-enterprise-gradle-plugin:3.10")
    settings.buildscript.dependencies.add("classpath", "com.gradle:common-custom-user-data-gradle-plugin:1.6.5")
  }
  settingsEvaluated { settings -&gt;
    settings.buildCache {
      local {
        enabled = true
      }
      remote(HttpBuildCache) {
        url = '<https://your.gradle.enterprise.server/cache/>'
        enabled = true
      }
    }
    if (!settings.pluginManager.hasPlugin("com.gradle.enterprise")) {
      settings.pluginManager.apply("com.gradle.enterprise")
    }
    if (!settings.pluginManager.hasPlugin("com.gradle.common-custom-user-data-gradle-plugin")) {
      settings.pluginManager.apply("com.gradle.common-custom-user-data-gradle-plugin")
    }
    settings.extensions["gradleEnterprise"].with {
      server = "<https://your.gradle.enterprise.server/>"
      buildScan {
        publishAlways()
        capture {
          taskInputFiles = true
        }
        uploadInBackground = System.getenv('GO_SERVER_URL') != null || System.getenv('GITLAB_CI') != null
      }
    }
  }
}```

We’re on groovy syntax, you’d need to swap it out for Kotlin if that’s what you’re using.
We opted to not use kotlin in the init script as the compile time for that was incredibly slow compared to Groovy.

<@U04NU3YN79Q> <@U02CJEY21C7> here are examples on how to configure publishing in the Groovy syntax for both <http://scans.gradle.com|scans.gradle.com> as well as your own Gradle Enterprise server from an init script: <https://docs.gradle.com/enterprise/gradle-plugin/#many-projects>

<@U042816HVD0> It almost seems to work, but I get
```* What went wrong:
Extension of type 'GradleEnterpriseExtension' does not exist. Currently registered extension types: [ExtraPropertiesExtension, GradleEnterpriseExtension, RefreshVersionsExtension]```

<@UFDR8S97S> this seems to work, however it's setting up the enterprise server URL rather than the build scan ToS

can you try the sample for `<http://scans.gradle.com|scans.gradle.com>`?

it is beneath the Gradle Enterprise sample

<@UFDR8S97S> it does work, thanks! However, it prints
```An internal error occurred that prevented a build scan from being created.
Please report this via <https://github.com/gradle/gradle/issues>```
with no further information.

(the build scan is actually created, and looks normal at first glance)

are you able to share the project's code?

The project is <https://gitlab.com/opensavvy/formulaide>, I just ran `./gradlew clean --scan` on the `main` branch

i see. do you use `--scan` in combination with the init script?

Yes, I added the second example you gave verbatim to the user home init script, then ran the above command

If you omit `--scan` does it still give you the internal error?

With `--scan` there is no error (but of course, it doesn't generate the scan)

I see. If you add `publishAlways()` inside the `buildScan` block in the init script and run without `--scan`, does it give the error?

No error, and it does generate the build scan :thinking_face:

thanks. that should help you out for now! i'll report the error internally

Thanks! If you create a GitHub issue/whatever, don't hesitate to send the link here so I can subscribe to it in case further information is necessary

I will link here if we create a public issue about this.

Issue filed! <https://github.com/gradle/gradle/issues/24884>

Small note, I was using the Kotlin DSL version of the build script, but it seems you managed to reproduce it with the Groovy DSL so I guess it's not relevant

Translation-wise it is fine except for one detail.
0777 != 777

left is an octal number, right is a decimal number

Kotlin does not know octal number literals

And really translated it would be `tasks.create`, but `tasks.register` is much better of course. :smile:

You could also write it as `val createCommitHook by tasks.registering(Copy::class) { ... }` if you prefer

Unrelated to the conversion, `rootProject.rootDir` does make little sense.
`rootDir` is the `projectDir` of the `rootProject`. So you get the project dir from the root project of the root project. :slightly_smiling_face:
Either just use `rootDir`, or actually use `rootProject.file(".git/hooks")` instead of `File(...)`

Thanks!

So `fileMode = 0x755` would also be incorrect? Because that _seems_ to work?

Depends on how you define correct.
It will be 03525, or 1877, or 0b0111_0101_0101.
If that is what you want, fine. But it will not be the same as 0755 would have been.

What you can do use octal mode is `fileMode = "0755".toInt(8)`

Okay. Yeah. I think I want typical 755 file permissions, so fileMode = "0755".toInt(8) is more clear to what i want to do. IMO. I think ill do that

Actually, you can leave out the leading 0.
As a number literal in Java and Groovy it tells the complier it is octal.
But as you already tell it by `(8)`, the leading 0 is just noise. :slightly_smiling_face:

related: <https://github.com/gradle/gradle/issues/21171>

IMO it would be nice if Gradle were to add an API using NIO types, such as
```filePermissions = PosixFilePermissions.fromString("rwxr-xr-x")```
(and maybe even a `setFilePermissions("rwxr-xr-x")` shortcut) but clearly that hasn't happened

I guess technically that API doesn't support the setuid/setgid/sticky bits, but I think it's reasonable to call that out of scope for Gradle anyway

additionally I suppose <https://ant.apache.org/manual/api/org/apache/tools/ant/util/PermissionUtils.html#modeFromPermissions(java.util.Set,org.apache.tools.ant.util.PermissionUtils.FileType)|https://ant.apache.org/manual/api/org/apache/tools/ant/util/PermissionUtils.html#modeFromPermissions(java.util.Set,org.apache.tools.ant.util.PermissionUtils.FileType)> is already callable in Gradle

```fileMode = PermissionUtils.modeFromPermissions(PosixFilePermissions.fromString("rwxr-xr-x"), PermissionUtils.FileType.REGULAR_FILE)
```
is a lot more verbose but with some shortcuts it could be clearer than octal

```java {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_11
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(11))
    }
}```

If you can, prefer using `--release` though:
```tasks {
  compileJava {
    options.release.set(8)
  }
}```
See <http://developer-blog.cloudbees.com/2014/12/beware-siren-target-call.html> and <http://www.draconianoverlord.com/2014/04/01/jdk-compatibility.html>

<@URQ797WRW> This does not work, I get:
&gt;     &gt; The new Java toolchain feature cannot be used at the project level in combination with source and/or target compatibility

<@UDC9Q9RD0>, thanks, the second link does not work

Also, <@UDC9Q9RD0>, the snippet you added compiles the bytecode to Java 8. I want the bytecode of Java 11 (55), but just make sure no language feature was used

With which version did you try? I tried with 8.1 before I sent it and it worked fine.

build.gradle.kts.kt

Try taking a look at the sample here: <https://docs.gradle.org/7.3/samples/sample_jvm_multi_project_with_code_coverage.html>. It’s from v7.3, but it’s still relevant.

Basically, on the producing side all Configurations should have some distinct Attribute. And on the consuming side you need to create a ‘hierarchy’ of Configurations: a parent Configuration, and children with more specific Attribute(s) that use `extendFrom()` to extend from the parent.

(sorry for my last message, somehow didn't see the question)

As all three artifacts are published in the same consumable configuration, you should be able to simply do it without the need to have separate configurations or `extendsFrom`.
So what is the problem you have with that setup?

it sounds like you are trying to do what the jacoco aggregator plugin already does? or is that unrelated to your ask?

&gt; you are trying to do what the jacoco aggregator plugin already does
<@U04NA0ETHCN> I’m duplicating the behavior a bit, but doing it in a custom way to support android and java simultaneously

&gt; As all three artifacts are published in the same consumable configuration, you should be able to simply do it without the need to have separate configurations or `extendsFrom`.
You’re right - I’ve actually modified my approach since then to publish the artifacts in 3 separate configurations however, so I guess my question still applies.

```val coverageExecFile: NamedDomainObjectProvider&lt;Configuration&gt; = ..
    val _executionData = coverageExecFile
        .get() // TODO find a way to avoid this `get()`
        .incoming
        .artifacts
        .artifactFiles
        .asFileTree
        .filter(File::isCodeCoverageExecutionFile)```
I didn’t know how to filter a configuration before, now I do. But I think it’s good to publish in 3 separate configurations?

It's fine to publish in three, then you don't need to filter but simply consume in three just like the jacoco report aggregation plugin does it.

FTR, I technically don’t want to publish as 3, bc I’ll want a outgoing variant that doesn’t include android ui test execution data. so I’ll still need sources/classes to be separate

Can you knit this together to an <https://stackoverflow.com/help/mcve|MCVE>? :slightly_smiling_face:

gradlemismatch.tar.gz

Here you go. You should be able to import that into Android Studio (I used Giraffe Beta). It should work straight away after Gradle Sync. Android Studio will recognize both configurations and show options to run `microapps.mylibraryapp` or `<http://androidapp.app|androidapp.app>` but only `<http://androidapp.app|androidapp.app>` works.

I'm sorry, I'm not an Android developer and have not and will not install Giraffe.
I though downgraded the AGP version to a version compatible with my IJ version.
There  `microapps.mylibraryapp` runs fine on the emulator.
`<http://androidapp.app|androidapp.app>` though fails to build.

Maybe you can share build `--scan`s of your tries.

Understandably.
But if you observed the same issue on IJ then it’s probably an issue with Gradle rather than AS. I’ve tried downgrading to Gradle 7.6 and the behavior changed. I could run `microapps.mylibraryapp` from the IDE.
I don’t see how I could how with `--scan` if gradle fails to find the task?
```Cannot locate tasks that match ':microapps:mylibraryapp:assembleDebug' as project 'microapps' not found in root project 'GradleMismatch'.```

&gt; But if you observed the same issue on IJ
I did not. Unless your description was wrong.
&gt; then it’s probably an issue with Gradle rather than AS.
Why? AS is just a customized IJ.
&gt; I’ve tried downgrading to Gradle 7.6 and the behavior changed.
Hm, bad, then I cannot help, maybe someone else can.
&gt; I don’t see how I could how with `--scan` if gradle fails to find the task?
`--scan` should almost always work.

I’m sorry, I misinterpreted your results.
You managed to get it working, which IJ version are you using?
I tried with IJ 2023.1 and the error message is different:
```Cannot locate tasks that match ':androidApp:microapps:mylibraryapp:assembleDebug' as project 'androidApp' not found in root project 'microapps'.```
It’s searching for the correct path `:androidapp:microapps:mylibraryapp:` but in the wrong root project.
&gt; `--scan` should almost always work.
It doesn’t when I try to run this specific task, just errors the same as before, since it doesn’t exist. Unless there’s another task I can run with `--scan`

&gt; You managed to get it working,
Well, the one you said is not working worked, the one you said working did not build
&gt; which IJ version are you using
2022.2.3
&gt; It’s searching for the correct path `:androidapp:microapps:mylibraryapp:` but in the wrong root project.
If you have multiple builds imported and want to run that task path in a specific build, you have to select which build, depending on how you run the task.
For example in the "Run Anything" dialog (`Ctrl-Ctrl`) you can select the execution context in the upper left.

If I Build the project as root <http://user.It|user.It> will work.How you able to achieve this on normal Admin user.

Maybe you do not have permissions to create `/Users/mugunthan/Projects/Workfreaks/node_modules/@capacitor/splash-screen/android/build` or something like that?

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

That's insane that it's still an issue, I'd have thought that would be a rather basic thing. I mean, they're writing a long living cache and daemon, idk why "log rotation" wasn't like the 3rd item on the list to check off

Especially in JVM land where we've got so many log options already

specifically, I have an outgoing variant that provides UI test results…..I don’t want these running in a `:subproject:assemble` scenario

It's totally obvious.
Set the configuration to `isVisible = false` :-)

thank you!! that did the trick. Documentation is very unclear here

Hm just a guess here but, it is getting run by 2 different tasks... So maybe check a variable to see if it's the one you want. Check if it's a maven repository coming in

Good hint - yes the `./gradlew publish`  task was executing multiple publishing tasts

In most situations you want `Sync` over `Copy`.
It removes files it didn't copy there itself.
The preserve afair is just to exclude some files from this cleaning, but not to not overwrite files.

But maybe you can use an `eachFile { ... }` closure where you check whether the target file exists and if so `exclude()` it or something like that.

weird..how do i get the right scope for the eachFile?

`eachFile *{* file *-&gt;* file.exclude() *}*`

`build.gradle.kts:43:14: Type mismatch: inferred type is ([Error type: Cannot infer a lambda parameter type]) -&gt; ??? but Closure&lt;(raw) Any!&gt;! was expected`

ah, seems i can just use it as this scope. but, oddly the lambda variables behave weirdly here. i suppose it confuses gradle kts' inferencing, so i would need to somehow expliclty specify whatever type that is

meh, i can just do it without file -&gt;

it's even more weird because `it` is invalid. it doesn't auto generate the `it` like kotlin normally does?

All the Gradle actions use the sam-with-receiver plugin. So what you expect to be "it" is "this".

thanks, that's the term i forgot about, sam-with-receiver

it’s magically working again now :woman-shrugging:

have had similar class-related oddness that is generally resolved by stopping the daemon.  imo corner-cases that end up with plugins / daemon having corrupt state.

That’s probably it! I’ve been working with a project that keeps OOMing &amp; freezing, so I had to force-kill all Java/Gradle processes. I thought that wiping `.gradle/cache` would help, but apparently not.

yea, have had a few odd things with the daemon holding onto state.  sometimes its bad plugins that have a static variable to ‘cache’ stuff, other times it’s harder to track down what caused the invalid state, but bouncing the daemon resolves it.

&gt; bad plugins that have a static variable to ‘cache’ stuff
:scream:

:face_palm: :rage: :face_with_rolling_eyes:

the weird thing is that I restarted my machine, cleared out all the caches, etc - but it still failed :woman-shrugging:

&gt; if build caching is enabled?
Even if you enable task output caching and the producer task in question is cacheable, this cannot be a problem. Why, you may ask. Well, the outputs of a task are packed into an archive that is stored into the cache, so it cannot be used from there directly. :slightly_smiling_face:
That is also the reason why for example task types like `Zip` or `Jar` or `Copy` are not cacheable, because it is usually faster to just create the archive or copy the files, than to get the archive from the cache - maybe even remote cache - and unpack it.

&gt; is it ok to just add something like
As the files are not generated by `other-project` but just there, and you have strict pathing requirements, I guess it is ok to do it like that, but don't nail me on it. :smile:
Btw. the `jacoco-report-aggregation` plugin registers an outgoing variant that contains the source files. (including generated ones I think if applicable)

Thanks, this is very helpful!
&gt; the outputs of a task are packed into an archive that is stored into the cache, so it cannot be used from there directly
ah, I see, so this is different from the maven dependencies cache, where jars can be placed on the classpath directly from the cache (because the jvm can read jars directly)
&gt; the `jacoco-report-aggregation` plugin registers an outgoing variant that contains the source files
this is fascinating! :smile: if I read <https://github.com/gradle/gradle/blob/b45fc72c2aa0c668d6025fe089cb4affac656100/subprojects/plugins/src/main/java/org/gradle/jvm/component/internal/DefaultJvmSoftwareComponent.java#L136> correctly, every jvm component has an outgoing variant for its main source files for report aggregation purposes

&gt; ah, I see, so this is different from the maven dependencies cache, where jars can be placed on the classpath directly from the cache (because the jvm can read jars directly)
Yes
&gt; every jvm component has an outgoing variant for its main source files for report aggregation purposes
Oh, right, I thought that plugin adds this variant, but indeed it just uses it, so yes you can just use that as you can see in `outgoingVariants` task output

try taking a look at Example 17 here <https://docs.gradle.org/current/userguide/java_testing.html#ex-setting-up-working-integration-tests>

it’s backwards to what you want (it creates a source set that depends on main, whereas you want main to depend on the created source set), but it should give an idea.

comparing it with your code, I think you might be missing an equivalent for this

```configurations["intTestRuntimeOnly"].extendsFrom(configurations.runtimeOnly.get())```


I would say the "current best way" would be to reconsider whether you really want such a source set. Maybe it'd be a better idea to create a separate project and simply add a dependency on it? or maybe a "feature variant" rather than a project? or if you want everything inside the same JAR then maybe just put everything into the main source set?
What are you trying to achieve with that separate "adapter" source set?

in adapter i want an interface, then i will add a different source set for each implementation, each compiled against a different version of a dependency, then i will choose which impl to use at runtime based on the version of the dependency on the classpath

right now i am doign a done of runtime reflection to support multiple versions of the upstream dependency

and this will probably be a better approach

i could do multi module, but this is already a sub build in a composite build and I am trying to avoid a complicated restructuring of everything, and I figured sourceset+configuration will be good enough for just one class i need

yeah <@U02KX5B7EVC> i need the reverse of that example.

i tried the extends from thing:
```    named("implementation"){
        extendsFrom(configurations.named("adapter").get())
    }```