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

Gradle Community

What is reachable and what is not is defined by the Java compiler. Gradle doesn’t do anything special here. So whatever is on the compile classpath is reachable (if javac allows it).
So to answer
&gt; Question: are other types in the same package reachable from the type’s AST?
They are reachable, since they are probably on the compile classpath.

BUT: incremental compilation might not work correctly, if you will reach them and try to do some decision based on that. Example:
Java sources:
```a/A.java with @MyAnnotation that create a class AList, with a list of all classes in the package
a/B.java```
So when we do first compilation and we reach other types, everything works ok, because Gradle does full recompilation:
```1. a/A.java is compiled to a/A.class
2. a/B.java is compiled to b/B.class
3. a/A.java generates a/AList.java with content below
4. a/AList.java is compiled to a/AList.class

package a;

class AList {

    public List&lt;String&gt; getClasses() {
       return Arrays.asList("a.A", "a.B");
    }
}```
All good.

But what happens when we delete a/B.java? Gradle doesn’t know that A, AList and B are related. So A won’t be passed to the compiler on incremental compilation and a/AList.java wont’ be updated.
And due to that AList.getClasses() will still return `Arrays.asList("a.A", "a.B")` . That is a silent failure/bug the docs is talking about.

And of course also if a new class is added to the package, like a/C.java, Gradle won’t know that it needs to pass a/A.java to the compiler and annotation processor won’t be run: due to that AList.getClasses() will still return `Arrays.asList("a.A", "a.B")` .

What I was thinking could happen during an incremental compilation of `A.java`: if you called `PackageElement.getEnclosedElements()` for `A`'s corresponding `PackageElement`, it may only be guaranteed to return the top-level types in the package that `A` depends on (including transitive dependencies), not all the top-level types in the package.

But now it seems like you can see all the top-level types in the package, even during an incremental compilation. Depending on that information, however, can introduce subtle bugs.

In this case, though, there is a valid reason to look at the info: if there's a class named `Override` in the package, your generated code needs to use `@java.lang.Override`, not `@Override`. (You could also detect this problem and raise an error, or just decide that you'll ignore this edge case altogether.)

On a related note, I did find a unique edge case where incremental compilation misses an error.
<https://github.com/gradle/gradle/issues/24736>

&gt;  On a related note, I did find a unique edge case where incremental compilation misses an error. 
Yes, there are these subtle corner cases indeed.

the name in `buildSrc/settings.gradle` is not `buildSrc`, though: <https://github.com/micronaut-projects/micronaut-serialization/blob/80322727f4dd5f71258b99e480f1285e5ad3f0c7/buildSrc/settings.gradle> (although it's probably wrong)

the stack trace seems to imply that `buildSrc` is included from a settings file.

it may be the cause of the problem, looks like a copy and paste error in this case, the `buildSrc` file shouldn't set its name to the name of the parent build

it's not, I think that's because Gradle now tries to align the behavior of buildSrc with the one of included builds

Yeah, it should set it to `buildSrc`.
I think I've seen that before.

`buildSrc` is still treated specially, so if you set a different name for its root project, it chokes

Did you set the property to enable the new feature?

Ok, THAT was missing.

```systemProp.org.gradle.unsafe.kotlin.assignment=true```
Silly me. :slightly_smiling_face:

Or said differently, you can remove it, but you then need to use the new name without unsafe

Release notes:
&gt; See <https://docs.gradle.org/8.1/userguide/upgrading_version_8.html#configuration_caching_options_renamed|the upgrading guide> if you were already using this feature in previous releases, as all `org.gradle.unsafe.configuration-cache...` properties were renamed to reflect the fact they are now fully supported.
Upgrade guide:
&gt; <https://docs.gradle.org/8.1/userguide/upgrading_version_8.html#configuration_caching_options_renamed|Configuration cache options renamed>
&gt; 
&gt; In this release, the configuration cache feature was promoted from incubating to stable, and as such, all properties originally mentioned in the feature documentation (which had an `unsafe` part in their names, e.g. `org.gradle.unsafe.configuration-cache`) were renamed, in some cases, by just removing the `unsafe` bit.
&gt; 
&gt; *Incubating propertyFinalized property*`org.gradle.unsafe.configuration-cache`
&gt; `org.gradle.configuration-cache`
&gt; `org.gradle.unsafe.configuration-cache-problems`
&gt; `org.gradle.configuration-cache.problems`*
&gt; `org.gradle.unsafe.configuration-cache.max-problems`
&gt; `org.gradle.configuration-cache.max-problems`
&gt; Note that the original `org.gradle.unsafe.configuration-cache…` properties continue to be honored in this release, and no warnings will be produced if they are used, but they will be deprecated and removed in a future release.
`git grep` only comes up with properties files, docs, tests, and `subprojects/core/src/main/java/org/gradle/initialization/StartParameterBuildOptions.java` where they are used as "deprecated name"

I’m aware of the migration guide, but that’s not something user will go to when upgrading their Gradle version when using our template project with such `unsafe` property set.
`StartParameterBuildOptions` and deprecated names is helpful here — but I didn’t notice such deprecation message in the console. :thinking_face:

They don't come yet, see the part form the upgrade guide

Right, thanks a lot for all details, Björn!

I just share what I know, I'm just another user :slightly_smiling_face:

It doesn't seem like there's a way to disable the debugger on the original process, so the best option may just be to add a `org.gradle.debugfork` property.
```tasks.withType(JavaCompile) {
    // The Error Prone plugin uses a forking compiler for JDK 16+.
    // The 'org.gradle.debugfork' option has been added to enable debugging on the forked process.
    if (System.properties.getProperty('org.gradle.debugfork', 'false').toBoolean()) {
        // Use port 5006 on the off chance that the original process is listening for a debugger on port 5005.
        options.forkOptions.jvmArgs &lt;&lt; '-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5006'
    }
}```

```$ ./gradlew clean build

FAILURE: Build failed with an exception.

* Where:
Initialization script '/Users/ummalhotra/.gradle/init.gradle'

* What went wrong:
Could not compile initialization script '/Users/ummalhotra/.gradle/init.gradle'.
&gt; startup failed:
  General error during conversion: Unsupported class file major version 64

  java.lang.IllegalArgumentException: Unsupported class file major version 64
        at groovyjarjarasm.asm.ClassReader.&lt;init&gt;(ClassReader.java:199)
        at groovyjarjarasm.asm.ClassReader.&lt;init&gt;(ClassReader.java:180)
        at groovyjarjarasm.asm.ClassReader.&lt;init&gt;(ClassReader.java:166)
        at groovyjarjarasm.asm.ClassReader.&lt;init&gt;(ClassReader.java:287)
        at org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(```


java --version
openjdk 20 2023-03-21
OpenJDK Runtime Environment (build 20+36-2344)
OpenJDK 64-Bit Server VM (build 20+36-2344, mixed mode, sharing)

Don't use an unsupported Java version: <https://docs.gradle.org/current/userguide/compatibility.html>

gradle --version

Welcome to Gradle 8.1!

Here are the highlights of this release:
 - Stable configuration cache
 - Experimental Kotlin DSL assignment syntax
 - Building with Java 20

Exactly, "Building" (using the toolchains feature)

then which java version should i use with this gradle?

That I answered already with the first answer :wink:

Ok, got it. Java 20 and later versions are not yet supported.

But actually I tried with open jdk Java 17 as well, But I had got a similar problem with that also.

I will try again and check if java 17 works

Thanks for the help. <@URQ797WRW>

If you got a problem with 17, then please tell which exactly, details are important :slightly_smiling_face:

What do you mean with "system proxy variables"?
If they are set as system properties in some way with the properties required by Java like `http.proxyHost` and so on, Gradle will also use those.
The docs you linked to show how to set these system properties from a `gradle.properties` file like `&lt;GRADLE_USER_HOME&gt;/gradle.properties`, but any way to properly set the needed system properties would work.

If you talk about environment variables named `http_proxy` , `https_proxy`, and `no_proxy`, those are not considered by any Java program.

I was talking about the latter, I see those variables consumed by other environments, so I was trying to understand if gradle would consume those too . Thanks. This helps!

Those environment variables are to my knowledge not any agreed on standard. Gradle does no own proxy handling, it just relies on Java doing its thing which afaik does not consider those environment variables, but only the mentioned system properties.

If you use it at execution time of the task, you should also declare it as input to not miss the necessary task dependencies.

I'm actually using it at configuration time (I believe), to build some specialized far JAR. See <https://github.com/oss-review-toolkit/ort/blob/ff05b2d8f0db6d0bbcbf123bf596ded88f7e75bd/plugins/package-managers/gradle-plugin/build.gradle.kts#L46-L51|https://github.com/oss-review-toolkit/ort/blob/ff05b2d8f0db6d0bbcbf123bf596ded88f7e75bd/plugins/package-managers/gradle-plugin/build.gradle.kts#[…]1>

I think the issue is, that at execution time, tasks are not executed yet. So you will get the stale jar from the last run if it is around or otherwise it will not be present and filtered out by your `isFile` check. Maybe it would work better with an artifact transform or maybe when using the `shadow` plugin.

Hmm, I though a line like `_configurations_._runtimeClasspath_.get().filter` would be evaluated lazily, at execution time, when all elements of the `runtimeClasspath` are actually present. Is that not the case?

you have to put the task execution logic in a `doFirst` or `doLast` block, otherwise it's all executed at configuration time

instead of doing `.get()`, try using `.map {}` so the Provider isn’t evaluated until necessary, and use <https://docs.gradle.org/current/userguide/dependency_resolution.html#sec:programmatic_api|the artifacts API>

```val classpath = configurations.runtimeClasspath
  .map { runtimeClasspath -&gt;
    runtimeClasspath
      .incoming
      .artifacts
      .artifactFiles
      .filter {
        // Only bundle JARs that are not specific to the Gradle version.
        it.isFile &amp;&amp; it.extension == "jar" &amp;&amp; !("gradle" in it.path &amp;&amp; gradle.gradleVersion in it.path)
      }.map {
        zipTree(it)
      }
  }```

<https://github.com/oss-review-toolkit/ort/blob/ff05b2d8f0db6d0bbcbf123bf596ded88f7e75bd/plugins/package-managers/gradle-plugin/build.gradle.kts#L59|line 59> looks odd, what’s it for? I think it can probably be removed. It’s usually best to keep things lazy

```    with(tasks.jar.get())```

I don't remember exactly, I've copied from from somewhere :slightly_smiling_face: I believe it's for also getting the JAR contents for *this* actual project, in addition to its runtime dependencies.

<https://docs.gradle.org/current/userguide/working_with_files.html#sec:creating_uber_jar_example|there’s an example in the docs for creating a fat jar>, which on the plus side is nice and simple, but on the downside it’s sometimes too simple and Shadow is better

If you’re publishing the plugins with the Gradle Plugin Publish Plugin then it this has support for using Shadow <https://plugins.gradle.org/docs/publish-plugin#shadowing>

While even `shadow` does not cover all edge cases that make fat jars a sin and bad-practice.
When I ever start a blog, the first entry will about "the good, the bad, and the ugly, when it comes to fat jars" :smile:

Thanks for pointing out the official example to me <@U02KX5B7EVC>, looks like the lazy evaluation by wrapping `runtimeClasspath.get()`  in `{}` inside `from()` is they key...

github packages is what you are looking for 

but if I am correct, they are not public (you need to pass auth to be able to download artifacts)

<https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-gradle-registry> although I think their documentation is bad, the conventional way to handle it in Gradle would be
```maven(url = "<https://maven.pkg.github.com/USER/REPO/>") {
    name = "GitHubPackages"
    credentials(PasswordCredentials::class)
}```
and
```env:
  ORG_GRADLE_PROJECT_GitHubPackagesUsername: ${{ github.actor }}
  ORG_GRADLE_PROJECT_GitHubPackagesPassword: ${{ secrets.GITHUB_TOKEN }}```
in your workflows

yes, even public packages require GitHub authentication

Hmm, is there an alternative? - a popular public maven repo to upload artefacts and access them without credentials?

nothing special about a maven repo, any static HTTP host will work (although Gradle requires it to support the HEAD method, so GitHub pages won't work)

long-term, if it's public you'll probably want to upload to Maven Central, which takes some initial account set up, but isn't that hard. you can find lots of guides about it online

sonatype snapshots repository or maven central repository using alpha, beta and so on

Please don't post alphas and betas to Maven Central.
Maven Central should imho only be used for real releases, not snapshot or preview builds.
For that, there is the Sonatype snapshots repository that you also have access to when having access to publish to Maven Central.

you can’t publish alphas or betas to snapshots repository as it only accept -snapshot versions 

I think it is common to publish those versions on maven central tho, for example kotlin ones are there

they upload dev releases to their own <https://maven.pkg.jetbrains.space/kotlin/p/kotlin/dev/>

&gt; I think it is common to publish those versions on maven central tho, for example kotlin ones are there
That some projects do it, does not mean I need to like it. :smile:
That always requires to then again filter them out from things like `gradle-versions` plugin, `refreshVersions`, dependabot, renovate bot, ...

<@U019L3NM4PK> I was referring to alpha, beta and rc

This is the main reason why I am asking - I preffer not to upload alpha/beta/snapshoot

but for snapshot you have the snapshots repository 

you want to avoid to renovate use the snapshot versions? If you keep a stable version on the remote, renovate will not update it to snapshot even if it is higher 

sonatype has staging repos. I think creating a maven central account also gives you one

but if you don't want them in maven central, it really is easy to set up your own repo anywhere

Gradle has built-in S3/GCS support, <https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:s3-repositories> <https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:gcs-repositories>, so you can easily publish to there, and if you make your buckets public, they can be consumed without auth over http

&gt; you want to avoid to renovate use the snapshot versions? If you keep a stable version on the remote, renovate will not update it to snapshot even if it is higher
Yeah, but it had to get special logic to not use such versions. And this logic is usually also driven by version string matching which might or might not be correct, ...
If Maven Central just had production versions, everything could just use it. :slightly_smiling_face:

I mean, renovate avoids using any non final version by default, except if you are using a non stable version, and a version which is higher but has the same major, minor and path is released

Supposing you are using 1.0.0-alpha.1
• release 1.0.0-alpha.2 would be updated by renovate
• release 1.0.1-alpha.1 wouldn't be updated by renovate
• release any final version would be updated by renovate
Supposing you are using final version, 1.0.0
• release 1.0.1-alpha.1 wouldn't be updated by renovate
• release any final version would be updated by renovate

Yes, I know and understood.
Now try to read again what I said.
They had to code that explicitly instead of just being able to use everything that is available in Maven Central.

And other tools like `gradle-versions` plugin you have to configure accordingly.

I don't know what you mean with "had to code" :thinking_face:

I guess he means that because there is a lot of non-release versions in maven renovate team had to figure this flow out implement custom logic to handle all of that. If maven would contain only release artefacts then this implementation would be much simpler.

BTW Good thanks that we have semantic versioning - just imagine how all of this would wok without it :joy:

Just imagine everyone would actually use semantic versioning, that would be a dream.

This is what I am using 

```pom.scm.url=<https://github.com/JavierSegoviaCordoba/hubdle>
pom.scm.connection=scm:git:git@github.com:JavierSegoviaCordoba/hubdle.git
pom.scm.developerConnection=scm:git:git@github.com:JavierSegoviaCordoba/hubdle.git```

That's not so much a Gradle question.
For Gradle that is just a plain String.
It is more a question for those that define or use the POM format.
So the authorative doc is <https://maven.apache.org/pom.html#scm> what it links to for Git.
But I think what you should use it the URL that you can copy&amp;paste 1:1 to a `git clone`, so should contain the `git@`.

`./gradlew buildEnvironment` is a dependencies report for buildscript

possibly the app you are using has bad dependency management. it could also be a JDK mismatch issue...like, if it was meant to build with JDK 8 and you are with 9...it removed the javax.* namespace

you may want to check that, and also run `gradlew dependencies`  and maybe that can tell you what's up

i am betting it is your JDK though, which needs to be &lt; 9, or the app updated, and/or override/exclude those dependencies

Thank you for the response!

Our app doesn't have many direct dependencies.

I did check ./gradlew dependencies and didn't notice any "FAILED" or "ERROR" text
But I am not a gradle expert!

Here is the output from ./gradlew dependencies
&lt;Sorry I thought the snippet would follow the message!&gt;
``````

I have JDK 8 (at least I think I have JDK 8)

```nzos@gpu-desktop2:~/dev/current$ java -version
openjdk version "1.8.0_292"
OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0ubuntu1~16.04.1-b10)
OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)```


Run gradlew build -i and ensure it's choosing to use that jdk using the output. I'm just poking in the dark here with not much info

Thank you very much for your help!  I'm running around in the dark with a blindfold on!

Here is the output of ./gradlew build -i
The working directory for the gradle daemon is /usr/lib/jvm/java-8-openjdk...

Yes, feature variants seem to be what you are after. But afaict there is no standard attribute that it just magically works for the consumer. For `android` vs. `standard-jvm` there is `org.gradle.jvm.environment` that is automatically set by the respective plugins.

So the consumer will have to choose the feature variant explicitly I think.

I'm ok with that. It wasn't clear to me how to set that on the consumer side. Are you aware of any examples showing how to use custom attributes in this way?

I don't think using attribute directly is the right way here, it is one level too low. Use feature variants, they are one level higher.

Is there an example of that? I'm not sure what I need to do in my app so that the correct variant is used

<https://docs.gradle.org/current/userguide/feature_variants.html#sec::consuming_feature_variants|https://docs.gradle.org/current/userguide/feature_variants.html#sec::consuming_feature_variants>

Variants provide capabilities. So by selecting a capability, your select the variant.

I think I have been confused my names. I use registerFeature to create a variant which defines attributes which I can match by requesting a capability?

A feature variant defines one or more capabilities and also attributes. Different feature variants do not necessarily have different attributes.
In your case the variants will have the same attributes but different capabilities and you select a capability on the consumer side.

In case of android vs standard JVM, your feature variants would have the same capabilities, but different attributes, so that automatically the right variant is selected.

it really depends on how you want to use this environment variable.

If you’re launching a JVM process, then you can set an environment variable for that process based on a property from `gradle.properties`.

Or if you just want some variable that might come from `gradle.properties` on one machine, but is set via an environment variable on another machine, then you can use a <https://docs.gradle.org/current/userguide/build_environment.html#sec:project_properties|project property>

Can you explain more about what you want to achieve?

Sure. I'm using JGit programmatically directly as part of my `build.gradle.kts` file. When probing for the Git system config, JGit eventually calls out to the system's `git`  CLI, which is incompatible with Gradle's new configuration caching. JGit's behavior can be suppressed by setting the `GIT_CONFIG_NOSYSTEM` environment variable, and that's what I'd like to do.

funnily enough I’m also trying to work around that JGit issue at the moment! It would be nice to have a build service for Git operations that was config-cache compatible

the only suggestion I have to set that environment variable for JGit is to try and use a build listener <https://docs.gradle.org/current/javadoc/org/gradle/BuildListener.html>

but the problem is, what happens if a Gradle is cancelled, or crashes? The ‘unset’ operation might not be called.

<https://stackoverflow.com/a/33805274/1127485|Looks like> an alternative could be use a custom FS that makes `getGitSystemConfig` return null.

Can you wrap jgit call to <https://docs.gradle.org/current/javadoc/org/gradle/api/provider/ValueSource.html|ValueSource> and can that make it compatible with cc?

More about ValueSource can be found in cc docs: <https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements:external_processes>

Basically idea is, that ValueSource can run anything, and it makes that “anything” cc compatible. And it invalidates configuration cache only when result of obtain method is changed. But it is important that whatever is in ValueSource is a fast operation, since it’s not cached.

<@U02DF9JDXJM> I tried with a top-level class in my `build.gradle.kts` file but I'm getting
```* What went wrong:
Could not create an instance of type Build_gradle$GitVersionValueSource.
&gt; Class Build_gradle.GitVersionValueSource is a non-static inner class.```

Looks like the problem is that I capture `rootDir` from the outer scope. What do I need to inject as a property to get access to the project?

You need to pass what you want to use in ValueSource via parameters, e.g.:
```// Kotlin
abstract class MyValueSource : ValueSource&lt;String, MyValueSource.MyValueSourceParams&gt; {

    private val logger = Logging.getLogger(MyValueSource::class.java)

    interface MyValueSourceParams : ValueSourceParameters {
        val rootDir: DirectoryProperty
    }

    override fun obtain(): String {
        logger.lifecycle("In value source: " + parameters.rootDir.get().asFile.path)
        return parameters.rootDir.get().asFile.path
    }
}

val provider = providers.of(MyValueSource::class) {
    parameters {
        rootDir.set(project.rootDir)
    }
    // or just parameters.rootDir.set(project.rootDir)
}

println(provider.get())```

But you can’t pass Project and similar complex structures (e.g. Configuration)

Thanks. As I have several JGit calls that each would require a separate `ValueSource`, I decided to go with the solution of a custom `SystemReader` as mentioned at <https://stackoverflow.com/a/59110721/1127485> instead.

I'm maybe a bit late to the party, but this works perfectly fine and only needs one `ValueSource`
to bootstrap JGit if a new Daemon was started
with not missing the system config which the SO answer causes:
```import org.eclipse.jgit.storage.file.FileRepositoryBuilder

plugins {
    id("org.ajoberstar.grgit.service") version "5.2.0"
}

abstract class JGitBootstrapper : ValueSource&lt;String, JGitBootstrapper.Parameters&gt; {
    override fun obtain(): String {
        FileRepositoryBuilder()
            .setWorkTree(parameters.projectDirectory.get().asFile)
            .build()
        return ""
    }

    interface Parameters : ValueSourceParameters {
        val projectDirectory: DirectoryProperty
    }
}

providers.of(JGitBootstrapper::class) {
    parameters {
        projectDirectory.set(layout.projectDirectory)
    }
}.get()

println(grgitService.service.get().grgit.head().id)```
This way the external proess execution at configuration time is properly wrapped in a `ValueSource`, and it is only done once in the daemon lifetime as it is done as part of a static initialization.

The actual Git operations done at configuration time then cause the accessed files and environment variables to be configuration cache inputs as usual.
So if you execute this snippet two times, the second time nothing is printed.
If you then create a new commit and rerun without other changes, it is rerun and prints again.

Diese Nachricht enthält interaktive Elemente.

*And* this is not even enough, because if I now change some source file, the dirty-state should change.
So practically any file in the project should be a configuration cache input and thus make the cache void.

Having this Git operation in a `ValueSource` instead, will execute the operation on every build and if changed even twice,
but only the final result is considered an input, so the remaining configuration phase can be skipped more often.

As this dirty-determination for me is then used in `processResources` to fill in a placeholder in a properties file,
there would be almost no case where the configuration cache could be reused if all files of the project would properly be input.

So it might be much better for overall performance if operations are indeed be done in a value source

I’m using `ProjectBuilder.builder()` in a test. I want to increase the log level for my package, is that possible?

I made an issue about this here <https://github.com/gradle/gradle/issues/24780>

I think the problem is related to KMP, I moved everything from `jvmAndAndroid` to `jvm` and it is working. Maybe `resources` dir is not being shared there. I will take a look

To get the resources I am using:

```Thread.currentThread().contextClassLoader.getResource(name)?.file?.let(::File)```

its also possible that resources don’t have a file representation if they are packaged in a jar

you mean the android part more than the `jvmAndAndroid` source set?

I can try to copy and paste it to android target

any use of resources from the classpath - there’s no guarantee of a backing file.  cleanest to process those using the inputstream.

yeap, it is the android one which is causing the issue

using inputstream would work on android too?

well, technically that would mean coping the file to a different place

I think for my use case it has no sense to get this functionality on Android, thank you, I TIL :slightly_smiling_face:

resources do exist on Android, but you never have any guarantee that they're backed by `File`

also even though they work, you should use Android's built-in assets instead of resources, as the former are packaged in a way that allows them to be read efficiently from the APK, while the latter cause <https://blog.danlew.net/2013/08/20/joda_time_s_memory_issue_in_android/>

Which Gradle release are you using? I think this issue is not longer present in 8.x

Otherwise, you would have to give one of the included builds another name. Like his:

<https://github.com/gradlex-org/build-parameters/blob/main/settings.gradle.kts#L4-L6>

```    includeBuild("gradle/plugins") {
        name = "build-parameters-gradle-plugins"
    }```

```------------------------------------------------------------
Gradle 8.0.2
------------------------------------------------------------

Build time:   2023-03-03 16:41:37 UTC
Revision:     7d6581558e226a580d91d399f7dfb9e3095c2b1d

Kotlin:       1.8.10
Groovy:       3.0.13
Ant:          Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM:          17.0.2 (Eclipse Adoptium 17.0.2+8)
OS:           Mac OS X 13.2.1 aarch64```


I'll try bumping to 8.1, and if not, try your other suggestion. Thanks Jendrik :pray:

Np.
:thinking_face: maybe there is something special in you setup. This is the related issue: <https://github.com/gradle/gradle/issues/17228> (which should be in 8.0)

Ah, it should have been cherry-picked to 8.0 RC3

How to exclude a task introduced by 3rd party lib or plugin. we are using Kotlin DataFrame to processs cvs etc which used KSP plugin to generated some schema data. But in the new version, we encountered several problems.  The KSP generated files can not be excluded from lint task.

<https://github.com/jeremymailen/kotlinter-gradle/issues/322>

There is an implicit `formatKotlinGeneratedByKspKotlin` task introduced by dateframe or ksp always executed.

How to exclude it in our project?

You don't say that updating Gradle changes the Kotlin version of you production project, do you?
That is changes teh Kotlin version of build logic code could quite well be, as Gradle defines the Kotlin version that is used at runtime.

Exactly this happens, the kotlin-stdlib dependency is bumped to 1.8.10 as well. I wouldn’t have noticed that if not for the Compose compiler plugin that said that I’m using Kotlin 1.8.10, while I only whitelisted the usage of Kotlin 1.7.21 via the Kotlin compiler flag `plugin:androidx.compose.compiler.plugins.kotlin:suppressKotlinVersionCompatibilityCheck=1.7.21`

I guess I’m doing _something_ wrong because clearly this should not happen.

I would also say it shouldn't happen, but hard to say for me without hands-on.

Anything I could do to debug into this a little more?

Can you maybe look at a build scan, that could clear things more up than just `dependencies` and `dependencyInsight`.
Actually debugging the dependency resolution is not the nicest experience as far as I remember.

I published a scan here: <https://scans.gradle.com/s/t4uy5q2tcd4hi/dependencies?focusedDependency=WzEwLDE1LDYsWzEwLDE1LFs5NjAsNl1dXQ&amp;toggled=W1sxMF0sWzEwLDE1XSxbMTAsMTZdLFsxMCwxNixbNjYyXV0sWzEwLDE2LFs2NjFdXSxbMTAsMTYsWzY2MSw2ODZdXSxbMTAsMTUsWzk2MF1dXQ|https://scans.gradle.com/s/t4uy5q2tcd4hi/dependencies?focusedDependency=WzEwLDE1LDYsW[…]EwLDE2LFs2NjFdXSxbMTAsMTYsWzY2MSw2ODZdXSxbMTAsMTUsWzk2MF1dXQ>

From what I can see my `kotlin-bom:1.7.21` constraint pops up in `releaseCompileClasspath` , but also `kotlin-stdlib:1.8.10` which is there because “releaseRuntimeClasspath uses version 1.8.10”. And `releaseRuntimeClasspath` uses 1.8.10 because “Conflict resolution: between versions 1.8.10, 1.7.21, 1.7.10, 1.6.21 and 1.6.20"

Hm, so why do you have 1.8.10 in the release runtime classpath?
Do you maybe there use `embeddedKotlinVersion` and thus get a different version by updating Gradle?

Or maybe the main problem is, that it's a DB project and thus is prone to be late and make problems. :smile: (Sorry, couldn't resist)

No, I don’t reference `embeddedKotlinVersion` anywhere myself.

Hehe, now I have a new DB joke even :slightly_smiling_face:

But you do depend on `org.jetbrains.kotlin:kotlin-parcelize-runtime:1.8.10` and `org.jetbrains.kotlin:kotlin-stdlib:1.8.10` in `releasRuntimeClasspath`, right?

If not, or not aware, maybe that's where you should set a breakpoint, at where this is added to that configuration.

Do I really need to resolve dependencies and artifact separately, and them somehow associate them manually via their IDs?

What's your usecase? Can you use <https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/Configuration.html#getResolvedConfiguration--|ResolvedConfiguration> which I believe gives you both the dependency hierarchy and its artifacts? (but not the details on the resolved variants) The <https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/ResolvableDependencies.html#getArtifacts--|ArtifactCollection> will give you similar information but also includes variants. If you need information specific to the resolution result (such as the selection reason) then it looks like you'd have to re-pair them yes :man-shrugging:

I need to check the classifier of a Maven JAR artifact that was resolved. Yes, I could use `ResolvedConfiguration`. I'm just surprised that I indeed seem to need to associate resolved artifacts manually to resolved dependencies, instead of just saying "give me the resolved artifact for this resolved dependency".

i'm following this incubating convention plugins sample, i added a file in ./convention-plugins/src/test/resources/test.yaml, and tried to load it from the classpath using getResourceAsStream

is there something i'm missing on gradle to make those resources available to tests?

<https://docs.gradle.org/current/samples/sample_incubating_publishing_convention_plugins.html>

The problem of the error message, is that you use Groovy DSL. With that often error messages are little helpful. The message you got means "somewhere within `java { ... }` you messed up the syntax, but I cannot tell you where". You typically have to randomly comment out and in things to find out what the problem is.

That is one of the reasons I recommend using Kotlin DSL. You instantly get type-safe build scripts, proper helpful error messages when messing up the syntax, and an amazingly better IDE support.

In your case the problem is, that `exports { ... }` is not a thing I've ever seen and I'm using Gradle since pre-1.0.

Thanks <@URQ797WRW> for quick response. I might be doing it incorrectly but based on my problem statement, please suggest how can I use only certain layer as dependency between modules.

Sorry, but I have no idea what your intention is, or what your snippet is supposed to do, or where you got it from.

Ok, my intention is "I have multi modules project and I am trying to expose only API layer/package from one module to other module". And for this I was looking different approaches.

That means if module 'A' has api and domain layer and module 'B' is having dependency on module 'A' but module 'A' wants to expose only api layer to module 'B'. I am trying to achieve it with gradle build <@URQ797WRW>.

Are you using JPMS?
i.e. the Java module system, so `module-info.java` and running on the module path, not class path?

Then the most trivial is to there define what you expose and what you don't as that is what it is for.

If you want to only do it Gradle-wise, you would either have one project for API and one for the other classes, or maybe have different source sets.
Greatly depends on the exact gory details, so hard to give a general recommendation.

Thanks <@URQ797WRW> right now I am using java 8 as mentioned in my last post. So I dont think I can use module-info.java. I am attaching screenshot and I have modules in name of proj_one and proj_two and trying to achieve conditional dependency in Gradle-wise.

Ah, right, did not see the Java 8, then of course no JPMS, yes.

What do you mean by "conditional dependency"?

If you just want to make sure `one` is only using `api` of `two` within your build, you might consider simply using something like `archunit` to verify such architectural constraints.

Otherwise as I said, you need to either split `two` into two projects, or at least two source sets.

Thanks <@URQ797WRW> it makes sense and thanks a lot for all your inputs

My tests say "no", but the sentence "Gradle compares the checksum of the inputs and outputs instead of *only* the timestamp of the files." at <https://blog.gradle.org/introducing-incremental-build-support> sounds like timestamps are taken into account.

That would be bad as changing branches touches files and so on

Other build tools might only compare timestamps, Gradle does not

That sentence might be slightly misleading

Yes, now that I'm reading that sentence for the third time, I see how it's supposed to be read :slightly_smiling_face:

The emphasis is on "instead", not on "only".

I guess it would be nice to remove the *only* - then it would be more precise, right?

Most probably a classloading problem.
The `KotlinCompile` class you search for in the init script is most probably not coming from the same class loader that is used to register the tasks in question. So as the classes come from different class loaders, they are technically different classes and you get no matches.

You can easily verify by printing out the class loaders from the init script and from the task where it works.

You might need to instead need to do something like
```tasks.configureEach {
    if (it.class.name == "org.jetbrains.kotlin.gradle.tasks.KotlinCompile") {
        ...
    }
}```
or something similar.

Btw. do not do `tasks.withType(...) { ... }`, that totally prevents task-configuration avoidance. Always do `tasks.withType(...).configureEach { ... }`.

Thanks <@URQ797WRW> for once again helping me out.
I tried printing all of the `tasks` out, from both a `gradle` `task` and an `init script` (as shown above).
And both of them printed a quite a different set of tasks. You can see the difference here <https://www.diffchecker.com/LA7U9InU/>

Am I’m missing something about the lifecycle of `Gradle` here?

Hey, <@URQ797WRW>. So turns out I had to use `tasks.all{}` to gain access to all of the tasks.
Accessing tasks like `def tasks = tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile)`  (like I have mentioned above) might not return all of the tasks. Again, I think this has to do something with the lifecycle of `Gradle`
(which I’m not completely sure about), but `tasks.all{}` seems to do the trick for me.

And thanks for the hint about comparing tasks with their class name, it is working perfectly.

Do not use `tasks.all` though, except for trying things out / debugging.
It completely circumvents task configuration avoidance, causing each and every task to be realized and configured eagerly and thus wasting your time.

Thanks for the heads up <@URQ797WRW>, could you please suggest an alternative way of achieving the same behaviour.
This is how my script looks so far:
```allprojects {
    afterEvaluate {
        tasks.all {
            if (it.class.name.contains("org.jetbrains.kotlin.gradle.tasks.KotlinCompile")) {
                kotlinOptions {
                    freeCompilerArgs += ["-P", "...."]
                }
            }
        }
    }
}```

Well, what I told you. `tasks.configureEach`, not `tasks.all`

There is no point in configuring tasks that are not realized anyway as they are not going to be executed.

Got it <@URQ797WRW>, thanks for the clarification.

not having run it surmising the issue is relative pathing of resources.  you want “/test.yaml” to match where that resource is located, where “test.yaml” will look relative to the class being loaded (“/com/myorg/test.yaml”)

^^ move the resource to match the package name, use an absolute path, or read the resource via the root classloader

<https://docs.oracle.com/javase/8/docs/technotes/guides/lang/resources.html>

thank you guys, i realized i was missing calling the root classloader in the java-&gt;kotlin conversion. i learned something new about the leading `/` today, too

Dunno why it should contain `kt` files.
But well, for library elements there is a compatibility rule that `classes` and `jar` are compatible.
If you only want the ones that are anyway there as classes, filter it by that after the resolution. If you want classes from everything, use an artifact transform that unpacks the class files from the jars.

In such case I just use `repositories { removeIf { .. } ; maven { .. } }`

But it's strange if <https://repo.maven.apache.org/maven2/> doesn't resolve, Apache Infra team are great at getting thing work reliably. Could you share what error do you get?

just got

```<http://repo.maven.apache.org|repo.maven.apache.org>.  83713   IN      CNAME   repo.apache.maven.org.```
from 1.1.1.1

well the CNAME itself isn't necessarily an issue (`*.<http://apache.org|apache.org>.` → `*.<http://maven.org|maven.org>`), but then `<http://repo.apache.maven.org|repo.apache.maven.org>` is answered authoritatively without an A or AAAA record

ahh, Chris pinged Sonatype on the issue 10 minutes ago:

&gt; **fluxo [3:34 AM]**
&gt; np. i pinged sonatype on the ticket

yaeh, `<http://maven.org|maven.org>` is under Sonatype control

first they broke new search interface at `<http://central.sonatype.com|central.sonatype.com>`, now they broke Central itself

&gt; well the CNAME itself isn't necessarily an issue (*.<http://apache.org|apache.org>. → *.<http://maven.org|maven.org>), but then <http://repo.apache.maven.org|repo.apache.maven.org> is answered authoritatively without an A or AAAA record
it's so similar that I first thought that it was cname to itself :grin:

anyway removing central by name or url and adding private mirror work fine for normal deps but sometimes has a race for `pluginManagement` unfortunately

I tried using an init script
```val fixupMavenCentralUrl = Action&lt;MavenArtifactRepository&gt; {
    if (url.host.equals("<http://repo.maven.apache.org|repo.maven.apache.org>", ignoreCase = true)) {
        url = uri(url.toString().replace("<http://repo.maven.apache.org|repo.maven.apache.org>", "<http://repo1.maven.org|repo1.maven.org>", ignoreCase = true))
    }
}
beforeSettings {
    buildscript.repositories.withType(MavenArtifactRepository::class, fixupMavenCentralUrl)
    pluginManagement.repositories.withType(MavenArtifactRepository::class, fixupMavenCentralUrl)
}
beforeProject {
    buildscript.repositories.withType(MavenArtifactRepository::class, fixupMavenCentralUrl)
    repositories.withType(MavenArtifactRepository::class, fixupMavenCentralUrl)
}```
which fixed my primary build but doesn't seem to apply to included builds

included builds have independent `Settings#pluginManagement#repositories`, `Settings#dependencyResolutionManagement#repositories` and `Project#repositories`, so you'll have to apply the fix for each included build

I dropped it in `~/.gradle/init.d/fixupMavenCentralUrl.init.gradle.kts` and it only applied to the top-level build, not included builds. if there's a non-invasive way to do that, I haven't found it

let me think for a bit, I somehow applied config to included builds from init plugin

i don't see any special handing for included build in the scripts for my previous job, just usual `gradle.beforeSetting { it.dependencyResolutionManagement { .. } }` that was somehow applied to both root build and included build (since i had a clause that added `gradlePluginPortal()` to `build-logic`. IIRC it was mostly on Gradle 7.x at the time I wrote it

thanks anyway. I assume Sonatype's gonna fix this soon so it's not that important, I was just hoping for a temporary workaround I could apply to our CI machines for the time being

btw it was applied twice: first time only to main `settings.gradle.kts` (when it resolves included builds) and then to both main settings and one from `build-logic`

<@U019L3NM4PK>, you may want to also add `dependencyResolutionManagement.repositories.withType(MavenArtifactRepository::class, fixupMavenCentralUrl)` to `beforeSettings` if some project use it instead of declaring repos in `build.gradle[.kts]`

see <https://gradle-community.slack.com/archives/CAHSN3LDN/p1681961339760859>

Init scripts should afair also apply to included builds automatically. Where it did not work before 8.0 was when using `--init-script`, but only on `buildSrc`. Included builds should even work then.

Same. Its’ been hours

```* What went wrong:
687
Could not determine the dependencies of task ':design-system:mlp-gallery:kspReleaseKotlin'.
688
&gt; Could not resolve all task dependencies for configuration ':design-system:mlp-gallery:kspReleaseKotlinProcessorClasspath'.
689
   &gt; Could not resolve org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.10.
690
     Required by:
691
         project :design-system:mlp-gallery &gt; project :design-system:mlp-processor
692
      &gt; Could not resolve org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.8.10.
693
         &gt; Could not get resource '<https://repo.maven.apache.org/maven2/org/jetbrains/kotlin/kotlin-stdlib-jdk8/1.8.10/kotlin-stdlib-jdk8-1.8.10.pom>'.
694
            &gt; Could not HEAD '<https://repo.maven.apache.org/maven2/org/jetbrains/kotlin/kotlin-stdlib-jdk8/1.8.10/kotlin-stdlib-jdk8-1.8.10.pom>'.
695
               &gt; <http://repo.maven.apache.org|repo.maven.apache.org>
696
   &gt; Could not resolve com.google.devtools.ksp:symbol-processing-api:1.8.10-1.0.9.
697
     Required by:
698
         project :design-system:mlp-gallery &gt; project :design-system:mlp-processor
699
      &gt; Could not resolve com.google.devtools.ksp:symbol-processing-api:1.8.10-1.0.9.
700
         &gt; Could not get resource '<https://repo.maven.apache.org/maven2/com/google/devtools/ksp/symbol-processing-api/1.8.10-1.0.9/symbol-processing-api-1.8.10-1.0.9.pom>'.
701
            &gt; Could not GET '<https://repo.maven.apache.org/maven2/com/google/devtools/ksp/symbol-processing-api/1.8.10-1.0.9/symbol-processing-api-1.8.10-1.0.9.pom>'.
702
               &gt; <http://repo.maven.apache.org|repo.maven.apache.org>: nodename nor servname provided, or not known```

Maven Central is down right now. As soon as Sonatype fixes issue on their side it should work again. As a workaround you could use <http://repo1.maven.org|repo1.maven.org> instead of maven central normal endpoint, see <https://gradle-community.slack.com/archives/CAHSN3LDN/p1681950685954379|previous thread>

anyway any org that depend on external repo should have local cache/proxy (for example nexus oss could be used to cache maven/pypi/npmjs/etc)