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

Gradle Community

That error is thrown if you try to import multiple toml files into one catalog, which is not supported.

You are pretty free how you want it.

You e. g. can have one version catalog per build, or you can have one version catalog with all versions at the root project and include that in all the included builds, is any middle way.

Can you elaborate on how can I include a version catalog that is defined in the root project for the included builds?

The error does not exactly reflect what I’m trying to do. I am trying to include the same toml file into the same catalog. I think I get this is error because I have the same catalog being setup in multiple places. Which I suppose is not the correct practice.

It is the right practice if I got you right. Can you show what you tried? Optimally with an MCVE.

&gt; Can you elaborate on how can I include a version catalog that is defined in the root project for the included builds?
&gt; 
Something like this in your included build's settings.gradle.kts

```@Suppress("UnstableApiUsage")
dependencyResolutionManagement {
  versionCatalogs {
    create("libs") {
      from(files("../gradle/libs.versions.toml"))
    }
  }
}```

Not exactly minimal but I have a repro project I’ve setup at <https://github.com/satyarths/composite-build> .
I have an android project and a plugin project which I’m adding to a separate root project and trying to share the same version catalog amongst them .

<@U021PMD2TL4> Do let me know if this is different from what I’ve done at <https://github.com/satyarths/composite-build/blob/main/settings.gradle.kts> and <https://github.com/satyarths/composite-build/blob/main/sample/settings.gradle.kts>.

Also I’m new to composite-builds so please do suggest if there is a better way to structure this :slightly_smiling_face: .

To start with, you should not use the `-all` distribution.
In your situation it has no pros at all.
It only wastes time, diskspace, and bandwidth for everyone running the build.

The `-all` distribution only has one advantage and only if you use Groovy DSL and only while you edit or debug the build scripts.
Even with Groovy DSL, it wastes the same things mentioned above for anyone or anything just executing the build.
Using the `-all` distribution is mainly a work-around for an IDE bug that hopefully gets fixed one day.



Another detail, but that is mainly optics, is that it is only unnecessary clutter to wrap `dependencyResolutionManagement` within `dependencyResolutionManagement` as you did it in multiple places there.



Regarding the problem, it is because `gradle/libs.versions.toml` is automatically considered.
So by importing "another" file into the "libs" catalog of your root `settings.gradle.kts` file you trigger the error.
There could be a leniency added that this is allowed for the same file, but currently it is not.
Just remove the declaration from the root `settings.gradle.kts` and it works.

Oh okay, I was using the all distribution so that I have access to sources. TIL that its not needed.

The nested dependencyResolutionBlocks is just copy pasta :see_no_evil: ..Will fix that.

So is it that `gradle/libs.versions.toml` would be automatically considered or is there a file pattern that would be considered be default?

Also do you mean I need not define the versionCatalog in any other  (`.gradle` )file? All the projects that are a part of the composite build would work?

`gradle/libs.versions.toml` is exactly the one that is considered automatically.
But only within that build. For the included builds you need to include manually like you have it if you want to use the same catalog.

I also created <https://github.com/gradle/gradle/issues/21328> if you like to thumbs-up it

Thank you , that helped. I’ve got the setup working.   Are there ways to share configuration across composite builds?  These could include for example plugins , dependency resolution and properties.
I’m not sure if that requirement makes sense though or if that could cause things to break .

The idiomatic way is to have in another included build convention plugins that do the shared logic and then in the other builds you can include that build and apply the convention plugin(s)

Came across a good resource to understand version catalog usage at <https://melix.github.io/blog/2021/03/version-catalogs-faq.html>

I was also reading into <https://github.com/gradle/gradle/issues/16078> to understand if declaring plugins in the version catalog is supported or not. The thread mentions that this is not supported, however the last example shows a way to use it. So is the conclusion that it can work but is not officially supported :thinking_face:?

There was a way in the beginning.
I complained because it was inconsistent and confusing.
Then they removed it.
Latter they added a better way.

So yes, you can declare plugins in version catalogs now. Better read the documentation instead of old tickets. :-)

Sure, I was searching the gradle documentation for information on this. And came across the ticket :sweat_smile: . Found the documentation at <https://docs.gradle.org/current/userguide/platforms.html#sec:plugins>.

Heavily depends on which parallelization you are talking about.

If you for example talk about the parallel running of tests JUnit Jupiter or also Spock are capable of, then this is a pure setup withing JUnit Jupiter or Spock.

If you for example mean you run with `--parallel` to have tasks of different projects run in parallel but don't want that for tests, then create a shared build service with max parallel usage 1 and declare all test tasks to use that service then it serves as exclusive lock.

Are you sure the Windows and Linux machine have the same amount of cores?

You mean "amount of"? Yes, it's exactly the same PC, dual-booted once on Windows, once on Linux.

Yes, of course "amount of", auto-correction. :smile:

So, this is how it looks on Windows, apparently 4 Threads being used:

And this is building the same on Linux on the same PC:

Ah, now that you show the concrete numbers I remember something that there was some problem with max 4 threads in some situations. Unfortunately I don't remember the exact details right now.

While it could of course also be that you limit the max workers using `&lt;GRADLE_USER_HOME&gt;/gradle.properties`

Also try printing `Runtime.getRuntime().availableProcessors()`

Here's the build scan from Windows: <https://scans.gradle.com/s/2zq5ugvdrypis>

Hm, so it was not the core detection. :-/

Is it maybe only a display thing? Like, as rendering to the console on Windows probably is not as fast as on Linux, only ever display 4 threads on the console, even if more are used?

Hm, was it maybe just a display error? At least according to timeline view all tasks were run in parallel

I just had the same thought, see above :slightly_smiling_face:

Yep, doesn't answer whether it is intentional though.

And in any case it's misleading. Even if the threads display was capped, the console output should say so.

Ha, when running Gradle on Windows in plain `cmd`instead of MinTTY that comes with Git Bash, I do see more threads being displayed!

Even under PowerShell or the new Windows terminal all threads are correctly rendered in the console...

Ah, yes, the thing I remembered was also about Git Bash

It's more MinTTY than Git Bash. As running Git Bash inside the new Windows terminal also gets the number of threads right.

Looks like this is the code in question: <https://github.com/gradle/gradle/blob/5ec3f672ed600a86280be490395d70b7bc634862/subprojects/logging/src/main/java/org/gradle/internal/logging/console/ConsoleLayoutCalculator.java#L37-L42|https://github.com/gradle/gradle/blob/5ec3f672ed600a86280be490395d70b7bc634862/sub[…]rg/gradle/internal/logging/console/ConsoleLayoutCalculator.java>

Probably boils down to <https://github.com/gradle/native-platform/issues/33>.

Ah, yeah, good find.
Probably onther report for core Gradle to add a hint if more work is done than displayed?
Even if the height can be calculated it uses at most half of the screen so even there more work than displayed could happen.

Done: <https://github.com/gradle/gradle/issues/21354>. Please upvote :wink:

&gt; It's more MinTTY than Git Bash. As running Git Bash inside the new Windows terminal also gets the number of threads right.
Quite possible, in Git Bash within ConEmu I also get the workers displayed properly.

example.kt

You don't need `Optional` in that case, use `convention` to configure the default value: <https://docs.gradle.org/current/userguide/custom_tasks.html#sec:writing_a_simple_task_class>

Oh that is much better. I can't say I'm a _*huge*_ fan of the injection magic with properties, but that's a conversation to made for all of Gradle tbf

I noticed that I had one @BeforeClass method to set up some system properties. Removing this, my tests executes properly and obvious fail as it depends on system property

```    @BeforeClass
    public static void assumeFeatureFlag() {
        assumeTrue("Feature flag is enabled", Boolean.parseBoolean(System.getProperty(FeatureFlags.REP_TYPE)));
    }```

Tests are getting ignored because of assumeTrue method where flag (sys property) is always false. I think i am missing mechanism to set the system property.

This question has absolutely nothing to do with Gradle. It is purely about whatever test framework you are using.
Besides that, the test is doing exactly what you tell it to. Assume the flag is true or else skip the test.

Two things:
• `Boolean.parseBoolean(System.getProperty(…))` is equivalent to `Boolean.getBoolean(…)`
• To set the system property for your tests, configure it on your test task: <https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html>

Or he simply sets the property in the `@BeforeClass` method using `System.setProperty` and maybe resets it to the previous value in `@AfterClass`.
With Spock as testing framework this could simple be done using a `@ResetSystemProperties` Annotation on the test. :slightly_smiling_face:

Removing `kotlin-dsl` lets the extension function resolve.

Iirc it should automatically have `stdlib-jdk8`. What's the code in question?

The code
```val path: Path = &lt;temppath&gt;
val expected = """
    &lt;expected dockerfile contents&gt;
""".trimIndent()
val actual = path.resolve("build/docker/Dockerfile").toFile().readText()
assertEquals(expected, actual)```
Specifically I have to call `toFile().readText()` because I can't get the `Path.readText()` method to resolve

the only diff between good-plugin or bad-plugin is `kotlin-dsl`

Although Gradle 7.5 bundles Kotlin 1.6.21, it still uses api version and language version 1.4 as that is what the 7.x line started with, to not break existing code in a minor Gradle version as far as possible.
The `kotlin-dsl` plugin also sets this api and language version accordingly.

I guess with Gradle 8.x it will be raised to 1.6, or even 1.7 if until then 1.7 is embedded.
Btw. you can use `kotlin("jvm") version embeddedKotlinVersion` in good-plugin to have the embedded kotlin version.

Seems you are running Gradle with a JRE and to compile Java code you need a JDK instead. You can also use the JVM toolchains feature to auto-provision the JDK your code needs independent from what is used to run Gradle.

Basically we have repository blocks everywhere, including in the `settings.gradle.kts` files (`pluginManagement`, `dependencyResolutionManagement`) as well as `buildSrc` and `includeBuilds`.

fwiw, i use plugins to apply standard company repo info to project dependencies, and for the pluginManagement repos, a custom gradle wrapper that has an init script that does it

Can you explain
&gt; a custom gradle wrapper that has an init script that does it (edited)
a little more?

and for
&gt; plugins to apply standard company repo info to project dependencies
do you mean a settings plugin? or a standard project plugin?

If you want to do it in `build.gradle.kts` scripts just add a settings plugin or normal project plugin in the root project that declares `fun DependencyHandler.company() = maven { ... }` in default (root) package to bring it to the classpath.

You also could add the company repo same way in the settings via `dependencyResolutionManagement.repositories { ... }` to avoid duplicating it in each build script. Delivery vectors are the same: a settings plugin or an init script classpath.

If you want to use it for `pluginManagement.repositories` then only an init script classpath is left. Though the init script could be delivered via local (for each developer) `~/.gradle/init.d` or a custom distribution's `init.d`.

YMMV but I tried approach with custom gradle distribution but eventually just wrote an open source plugin, published it to the plugin portal and it automagically adds private repo to both `pluginManagement` and `dependencyResolutionManagement` with simple application of the settings plugin (among other opt-in things like adding version catalogs and plugin declarations to the settings' `plugins` block from simple properties file). If interested in the details take a look at <https://gradle-community.slack.com/archives/CA745PZHN/p1657944560799889>

As for custom wrapper distribution, see <https://docs.gradle.org/current/userguide/distribution_plugin.html|https://docs.gradle.org/current/userguide/distribution_plugin.html> it's another option if publishing a settings plugin to the public gradle plugin portal is not feasible for you

I've run into a strange issue. I have a "toplevel" project which depends on a platform and directly on a few other dependencies, and has failOnVersionConflict turned on. Those dependencies conflict on a transitive dependency which is not handled by the platform, so I tossed a constraint into the toplevel project to cover it for now. However, when I wrote that constraint into the toplevel project, a subdependency of the now-constrained transitive dependency raised a version conflict. What is strange about this, is that the subdependency should be covered by a strict constraint in the platform. Adding yet another (matching) constraint to the toplevel project fixes this... but the issue cascades to more dependencies. I do not understand how constraints between projects interact and how inheritance is handled. Or perhaps I've landed on a Gradle bug?

Not a bad question at all.
Native libraries and Java is almost always a horrible topic and it is best avoided.
A good library needing native libs contains all of them and decides at runtime which to use.
If it has different variants for different platforms and it is built with Gradle, the best would be it indeed uses proper Gradle variants that could then be selected based on the the operating system it is built on. You could probably use component metadata rules to fix up the metadata of that library if it for example is different artifacts of the same library coordinates.
As a last resort, you can always use code like `Os.isFamily(Os.FAMILY_MAC)` in your build logic to decide what to do.

I publish a _lot_ and have never needed this

gradle plugins can fail on parallel if you have a lot 

is that with the latest version of the plugin publishing plugin? they just released 1.0

I haven't tried with 1.0.0 because I haven't a lot of plugins now in the same repo

Everything was working fine until it wasn't :sweat_smile:

Looks like at a certain point, running things in parallel <https://issues.sonatype.org/browse/OSSRH-5454?focusedCommentId=1036093&amp;page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1036093|causes issues with nexus>

in my case all plugins were published correctly in nexus but after that they failed in portal

I am on mobile but what about getting the task collection and pass it to the depends on instead of nesting?

You could collect task names for all signing tasks if they have some kind of regular names (using `tasks.names.filter { .. }`) and then use `tasks.withType&lt;AbstractPublishToMaven&gt;().configureEach { dependsOn(signTaskList) }`

Another way is to register dummy task, have it depend on all signing tasks and make all publish to maven tasks depend on it

That is if I understood correctly what you do want in this case of course

```public inline fun &lt;reified T : Task&gt; TaskContainer.namedLazily(
    name: String,
    action: Action&lt;in T&gt;? = null,
): TaskCollection&lt;T&gt; {
    val collection: TaskCollection&lt;T&gt; = withType&lt;T&gt;().matching { it.name == name }
    if (action != null) collection.configureEach(action)
    return collection
}```

this should be lazy, but you shouldn't need the matching part because you want all tasks that withType returns 

<@U01DUV4Q882> how would I get all the publishing tasks?

<@U01DUV4Q882>, aren't tasks realized on calling `matching`? I surely hope not but am not sure about it.

val publishingTasks = tasks.withType&lt;Publish&gt;()

<@UJUMPU407> <https://melix.github.io/blog/2022/05/gradle-laziness.html|https://melix.github.io/blog/2022/05/gradle-laziness.html>

So far I have:

```val signingTasks = tasks.withType&lt;Sign&gt;()
tasks.withType&lt;AbstractPublishToMaven&gt;().configureEach {
  dependsOn(signingTasks)
}```
which at least doesn't have any errors with a dry run. Now to actually test it.

iirc all publish task registered by maven-publish plugin have regular names so you could match them using simple regex. They had names like `publish(PublicationName)To(RepositoryName)Repository`

Interested on your results, share here please :)

<@UJUMPU407> I originally had something like that where I iterated through the targets and built the task names from their publications but it was getting long and more complicated than I wanted

In my case for maven I am using nexus publish plugin so I have publishToSonatype task too

So matching is eager as I remember. But `tasks.withType&lt;T&gt;().matching { .. }` would only realize tasks of type `T` as expected.

Looks like

```val signingTasks = tasks.withType&lt;Sign&gt;()
tasks.withType&lt;AbstractPublishToMaven&gt;().configureEach {
  dependsOn(signingTasks)
}```
did the trick :smile:

Yes, that's the very first suggestion of Javi :-)

<@UJUMPU407> exactly. That's why you usually should prefer an `if` in the configuration block if you don't need the actual collection, but want to configure depending on name. :-)

Probably something older than 7.4 where that method was added as a replacement for `alias`.

Thanks <@URQ797WRW> my gradle version was 6.5 ..changed it to 7.4 and it worked !

no, it was available before but needed to be activated in settings.gradle (`enableFeaturePreview("VERSION_CATALOGS")`

Ok sorry for the double post :confused: I will delete it and will take your advices in consideration, thanks a lot :wink:

Thinking about it more, would I actually need a plugin, or could I have a library that I depend on in the `settings.gradle.kts` buildscript, that provides function I can call that will add a repository?

Both should work fine I think.
Actually, there was a bug that when you add a repo from a settings plugin to `pluginManagement.repositories` the implicit Gradle Plugin Portal repo was not suppressed, but that should be fixed with 7.5 iirc.

Untitled.kt

I'm trying to add a repository to `pluginManagement` with a settings plugin, but I'm having trouble setting up an extension for it.

I keep getting an error saying that `ejsonSecretsFile must be set`, even though I'm setting the `password` property in the extension in `settings.gradle.kts`

You create the extension and then immediately check password and ejsonSecretsFile, what else do you expect, than then being unset?

Same as always. Best is you don't. Add a function / functions to your extension instead.

A function on the extension that will add the repository?

Also, do I have to do something special to configure the extension by name, e.g.

```addGitHubPackagesRepoToPluginManagement {
  owner = ...
}```
I keep getting an error saying that it doesn't exist.

But if I do:

```configure&lt;GitHubPackagesPluginManagementRepoPlugin.Extension&gt; {
  owner = ...
}```
Then it works

&gt; A function on the extension that will add the repository?
&gt; 
Exactly

&gt; Also, do I have to do something special to configure the extension by name
&gt; 
How do you apply it?

&gt; Also, do I have to do something special to configure the extension by name
For settings plugin, yes. Add an extension function with signature `fun Settings.addGitHubPackagesRepoToPluginManagement(configure: Action&lt;in GitHubPackagesPluginManagementRepoPlugin.Extension&gt;)` in the default package

Oh interesting so it's not made for you like Project plugins? 

Is that documented somewhere?

Not sure if it is. But there were some issues on the github like <https://github.com/gradle/gradle/issues/11210>

Or <https://github.com/gradle/gradle/issues/21381|21381> for a remake of the issue :slightly_smiling_face:

I wonder if java only plugin can provide such an extension

I wonder like the new reporter how it works for the Gradle enterprise plugin, where navigation in the IDE brings you to a `Project` extension function which seems wrong.
Both, it being generated and also being taken there. :confused:

Plugin itself contains `org.gradle.kotlin.dsl.GradleEnterpriseKt` with `public fun Settings.gradleEnterprise(GradleEnterpriseExtension.() -&gt; Unit): Unit` and `public val Settings.gradleEnterprise: GradleEnterpriseExtension` so I guess that the ones with `Project` are generated the same way as for the project plugins and IDE finds them but not from settings buildscripts classpath. I had to add `com.gradle.enterprise` manually to the dependencies for IDEA to show `com.gradle:gradle-enterprise-gradle-plugin` in the `External Libraries`.

Yeah, I've seen those manual extensions in `org.gradle.kotlin.dsl.GradleEnterpriseKt` by navigating to the extension from the settings script and using the breadcrumb toolbar in IntelliJ to navigate around the jar.
But still, afaik for settings script there should be no accessor generation at all,
and even if I do `settings.gradleEnterprise { ... }` navigation takes me to the project accessor which does not make much sense.

Thought the same but they are generated and `kotlinDslAccessorsReport` task prints them. And it seems <https://github.com/gradle/gradle/blob/master/subprojects/kotlin-dsl-provider-plugins/src/main/kotlin/org/gradle/kotlin/dsl/provider/plugins/DefaultProjectSchemaProvider.kt#L76-L81|same code> collects all `ExtensionAware` objects visible from project perspective.

```plugins {
  id("com.gradle.enterprise")  version "3.9"
}

gradle.rootProject {
  val schema = serviceOf&lt;ProjectSchemaProvider&gt;().schemaFor(this)
  schema.extensions.forEach { logger.lifecycle("ext: $it") }
}```
produces

```ext: ProjectSchemaEntry(target=org.gradle.api.Project, name=ext, type=org.gradle.api.plugins.ExtraPropertiesExtension)
ext: ProjectSchemaEntry(target=org.gradle.api.Project, name=buildScan, type=com.gradle.scan.plugin.BuildScanExtension)
ext: ProjectSchemaEntry(target=org.gradle.api.Project, name=gradleEnterprise, type=com.gradle.enterprise.gradleplugin.GradleEnterpriseExtension)
ext: ProjectSchemaEntry(target=org.gradle.api.artifacts.dsl.DependencyHandler, name=ext, type=org.gradle.api.plugins.ExtraPropertiesExtension)
ext: ProjectSchemaEntry(target=org.gradle.api.artifacts.dsl.RepositoryHandler, name=ext, type=org.gradle.api.plugins.ExtraPropertiesExtension)```

Though even in `afterEvaluate` I don't see my extension from settings plugin there, only genuine project-related ones (like version catalogs, extra properties for every `ExtensionAware`, and project plugin extensions). So I would guess that it hails from some special handling for blessed `buildScan`/`gradleEnterprise` extensions.

if you use Kotlin DSL, Gradle will convert it to lambda-with-receiver at runtime, so it's identical to using a lambda anyway

this is in your public API. Internally, use whatever you want

OK thanks, I though that was the case, but I see that Gradle uses lambdas in `org.gradle.kotlin.dsl` so I wasn't 100% sure

Is it OK to use default params in the public API, e.g.

```public fun Foo(action: Action&lt;Bar&gt; = Actions.doNothing())```

I'm not sure Groovy DSL would understand that. Maybe with `@JvmOverloads`?

In either case, that would only be an issue if I tried to use that API from a Groovy script, right?

IIRC Gradle works with actions just fine from groovy dsl

Yeah gradle ships some nice interop glue. I have used this to be able to expose groovy closures as typed lambdas in kotlin outside of the gradle context: 

```fun &lt;T&gt; Any.closureOf(action: T.() -&gt; Unit): Closure&lt;Any?&gt; = 
     KotlinClosure1(action, this, this) 
  
 /** 
  * Adapts an unary Kotlin function to an unary Groovy [Closure]. 
  * 
  * @param T the type of the single argument to the closure. 
  * @param V the return type. 
  * @param function the function to be adapted. 
  * @param owner optional owner of the Closure. 
  * @param thisObject optional _this Object_ of the Closure. 
  * 
  * @see [Closure] 
  */ 
 class KotlinClosure1&lt;in T : Any?, V : Any&gt;( 
     val function: T.() -&gt; V, 
     owner: Any? = null, 
     thisObject: Any? = null 
 ) : Closure&lt;V?&gt;(owner, thisObject) { 
  
     @Suppress("unused") // to be called dynamically by Groovy 
     fun doCall(it: T): V = it.function() 
 }```

Project is `kotlin("jvm") version "1.6.10"`  with gradle 6.8
Plugin is 1.6.21 built with gradle 7.4

`kotlin("jvm") version "1.6.10"` should not be mixed in with Gradle plugin/task development; that is via `kotlin-dsl`and pulls in the Gradle-embedded kotlin.

Hi Chris.  Just back to this from a long weekend.  Not sure I fully understand.  Should I add kotlin-dsl and remove the kotlin("jvm") part?

correct.  `kotlin-dsl` provides the Gradle-appropriate Kotlin libs (and includes `java-gradle-plugin` as well).

I need the app to have the kotlin version 1.6.10 however so something still seems off.

I tried as  you mentioned but got the same error:

My plugins section looks like this:
```plugins {
    java
    `kotlin-dsl`
    // kotlin("jvm") version "1.6.10"

     id("com.ea.gradle.gradle-plugin.assertscans.healthycode.HealthyCodeScan") version "6.5.2-SNAPSHOT"
}```


two different things.  Plugin/task development projects use `kotlin-dsl`.  Application projects (that use Kotlin) use `kotlin("jvm")`

I might have explained this poorly.  The plugin is done and written and works in other projects.  This other application project I'm adding it to generates the `Execution failed for task ':healthyCodeScan'. &gt; kotlin/jvm/JvmInline`   So adding kotlin-dsl to the application project isn't what I need.

Ah.  It looks like your published plugin is for an incompatible version of Gradle.

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

app project is 1.6.10 and the plugin is 1.6.21.

what Gradle version was the plugin compiled with?  What Gradle version are you running the plugin on?

Based on the compatibility link you sent.

yep.  The Kotlin version in 6.8 is a mismatch to the plugin/7.4 version.

generally you don’t want to use the same plugin version across major Gradle releases.

<https://github.com/FasterXML/jackson-module-kotlin/issues/523|this> appears to be what is tripping you up; proper fix is to provide Kotlin 1.5+, which is Gradle 7.2+.

FYI, downgrading Jackson in the plugin from 2.13 to 2.12 did the trick here so the app did not need to change.

I tried using `compileOnly` in my library, but now when I use the library in one of my projects I get the error:

```Unable to load class 'org.jetbrains.kotlin.gradle.plugin.KotlinBasePluginWrapper'.

This is an unexpected error. Please file a bug containing the idea.log file.```

I only get the error above if I have the following in my `settings.gradle.kts`

```buildscript {
  repositories {
    mavenLocal()
  }

  dependencies {
    classpath("my-library")
  }
}```
If I take that out, then everything works.

However, I want to use a function from my library in the `dependencyResolutionManagement` block to add a repository (I have `repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)` set).

I can add the `buildscript` block above to `build.gradle.kts` and then everything works fine (except I can't use the library to add the repository).

I just tried in another project and it works fine :thinking_face:

The only thing that's different about the project that doesn't work is that it uses `kotlin-dsl`

I think `compileOnly` is the good call. More generally, your lib also shouldn't have `kotlin-stdlib` in its dependencies so you should have `kotlin.stdlib.default.dependency=false` (but that is most likely not really related to your immediate problem)

```Unable to load class 'org.jetbrains.kotlin.gradle.plugin.KotlinBasePluginWrapper'.```
Do you have the stacktrace for this? Every code you write that needs the KGP symbols needs to be called from something like
```plugins.withId("org.jetbrains.kotlin.jvm") { // or ".multiplatform"
  // do stuff here
}```

And for classloading to work, you certainly want to isolate such code in separate classes that the JVM doesn't try to load until it has loaded the KGP jar

For an exemple, we're doing <https://github.com/apollographql/apollo-kotlin/blob/main/apollo-gradle-plugin-external/src/main/kotlin/com/apollographql/apollo3/gradle/internal/KotlinPluginFacade.kt#L14|this>

The stacktrace is much longer, but here's the relevant part. I'm thinking it's related to the library using `compileOnly` for the kotlin plugin, but if I add the kotlin plugin as a classpath dependency in the project the error still occurs.

```* Exception is:
java.lang.NoClassDefFoundError: org/jetbrains/kotlin/gradle/dsl/ExplicitApiMode
        at com.eygraber.gradle.kotlin.KgpKt.configureKgp$default(kgp.kt:17)
        at Build_gradle.&lt;init&gt;(build.gradle.kts:27)
        at Program.execute(Unknown Source)
        at org.gradle.kotlin.dsl.execution.Interpreter$ProgramHost.eval(Interpreter.kt:532)
        at org.gradle.kotlin.dsl.execution.Interpreter$ProgramHost.evaluateSecondStageOf(Interpreter.kt:438)
        at Program.execute(Unknown Source)
        at org.gradle.kotlin.dsl.execution.Interpreter$ProgramHost.eval(Interpreter.kt:532)
        at org.gradle.kotlin.dsl.execution.Interpreter.eval(Interpreter.kt:184)```

You don't control the loading of the KGP, you can only react to it with `plugins.withId("org.jetbrains.kotlin....") {}`

Well, if you add it as a runtime dependency, you technically control it but that's going against what another script might want to do

Gradle classloaders are surprising to say the least so depending where you add it, it might not be seen everywhere

I tried that, and it still doesn't work. In the library I use `plugins.withType(KotlinBasePluginWrapper::class.java)` before interacting with it, and in the project I tried wrapped the usage of the library in that and it still didn't work.

I have 2 plugins that are `compileOnly` in the library; detekt and Kotlin. If I make Kotlin `implementation` then the error changes to not being able to load detekt classes

&gt; plugins.withType(KotlinBasePluginWrapper::class.java)
Can that even work? That'd mean `KotlinBasePluginWrapper` is already in the classpath...

You might have a different version of the KGP than what you'd expect

What I'd do is remove all buildscript.classpath dependencies from `settings.gradle.kts` and `build.gradle.kts` in your project and load everything from regular (non-buildscript)  `buildSrc` dependencies

Using this, dependency and conflict resolution usually work as expected given that all your dependencies are in a single place

Looks like the issue is that because I am adding the library in `settings.gradle.kts` buildscript, and because the library has a `compileOnly` dependency on `kotlinGradleDsl`, there is no implementation being used.

If I add `classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:1.6.21")` to the `settings.gradle.kts` buildscript then it works, but if I only add it to the `build.gradle.kts` buildscript it doesn't work, even though the `NoClassDefFoundError` is happening in the `build.gradle.kts`.

So to simplify the problem, I have a library that applies `kotlin-dsl`, and a project that has a classpath dependency on that library in `settings.gradle.kts` and applies `kotlin-dsl` in `build.gradle.kts`

Unless I include a classpath dependency on `kgp` in the project's `settings.gradle.kts`, I get `NoClassDefFoundError` for code that's called from the library in `build.gradle.kts`

Do you need the `settings.gradle.kts` part? Usually KGP and others are applied in `build.gradle.kts`

I have a function in the library that configures a maven repo for github packages, and I need to use it in `dependencyResolutionManagement` because I have `repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)` set (which only allows repos to be configured in that block in `settings.gradle.kts`)

"Maybe" (with a lot of quotes), the settings classloader is a parent of the build.gradle.kts classloader and therefore doesn't see the KGP because it's loaded in a child classloader

That'd explain why your lib classes cannot see the KGP classes somehow

In which case you'd have to either:
• load everything in the settings classloader
• or split your lib in 2, one settings part and one build part

Again, this is "just" a wild guess, this stuff is hard

The funny thing is that I'm loading it in the `build.gradle.kts` buildscript as well, and everything works fine as long as I don't load it in the `settings.gradle.kts` buildscript

That'd be consistent with the "classloader" hierarchy

Ah well maybe not. If it's loaded twice, your `build.gradle.kts` should take precedence

<https://storage.googleapis.com/programming-idioms-pictures/idiom/149/princess-java.png>

Yeah this is a real head scratcher. Thanks for helping!

I'm afraid that some of this has been a wild goose chase, and I've been asking the wrong questions. I originally tried using `compileOnly` for kgp and detekt because of this error:

```Error resolving plugin [id: 'io.gitlab.arturbosch.detekt', version: '1.21.0']
&gt; The request for this plugin could not be satisfied because the plugin is already on the classpath with an unknown version, so compatibility cannot be checked.```
 By adding the kgp dependency as implementation instead of compileOnly the issue is resolved.

However I now get a `NoClassDefFoundError` for detekt plugin classes.

So the issue is that if detekt is `implementation` I get the error about resolving the plugin, and if it is `compileOnly` I get the `NoClassDefFoundError`. Adding the detekt plugin to the `settings.gradle.kts` buildscript dependencies results in the error about resolving the plugin.

And now I realize the problem is that because the library brings kgp and detekt onto the project's classpath, I can't specify the version when applying the kgp and detekt plugins.

However, I'm applying them using version catalogs (`alias(libs.plugins.kotlin)`, etc...) which I thought should allow the same version to be specified (<https://github.com/gradle/gradle/pull/19015>) however I just realized that Gradle doesn't know the version of the plugin on the classpath, which is not supported.

So the solution is to use `implementation` for the plugins in the library, and not specify the plugin version in the project :see_no_evil:

Yeah, with Gradle 7.2 the security in the start script got tightened, to prevent some execution attacks through variable expansion.

You basically have two options.
Either you use replacements in `doLast` to modify the start script how you want it, or you use a custom template for the start script that contains whatever you like.
The replacement way has the advantage to also get future improvements for the start scripts automatically as long as the replacements stay compatible.

Mmm yes. Android applications are terminal modules, they can't really be used as a dependency

in general, jvm cannot depend on android. The other way around is fine though

You can have this:
```plugins {
  id("com.android.application")
  id("org.jetbrains.kotlin.android")
}

dependencies {
  implementation(project(":jvm-only"))
}```


but not the other way around as <@UES7RHBDZ> said

I guess this applies to `id("com.android.library")` as well?

Yes, Android uses `.aar` files that JVM in general doesn't understand

Android ships resources and other things in their `.aar` and has some APIs that are not available to JVM (`Context, Views` , etc..). If you want to consume that from a JVM project, you'll have to isolate the non-android parts

Is there a reason you are not simply using a composite build?
Your use-case sounds like that is exactly what you actually want.

But to answer the question, you can get various Models from the `ProjectConnection`, for example using `.getModel(org.gradle.tooling.model.gradle.ProjectPublications::class).publications`.

If catalog is defined in the same settings script then no. The build script classpath is already composed to run actual settings script which loads catalogs.
Of course you could try load them manually in settings plugin but it would be fragile. Much better just to use catalog in an included build and apply required settings plugins from your settings plugin

It shouldn't matter since it's loaded via same API in the `dependencyResolutionManagement` <https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/configuration/BuildTreePreparingProjectsPreparer.java#L72-L88>

iirc you cannot use the version catalog in the settings script at all - no matter where, as they are only created during evaluation of the settings script.
Without parsing the TOML file manually that is.

Hey, is it possible to access the constraints of an `enforcedPlatform` in a task? I've tried `configuration.implementation.getAllDependencyConstraints()` but that doesn't include enforcedPlatform constraints.

It shouldn't be necessary actually.
The init script is applied to both builds automatically.

at least not when using
```pluginManagement {
    includeBuild 'build-logic'
}```


aaah. its not that black and white it seems. it works for parts of the included build.
Having this setup:
```// settings.gradle

pluginManagement {
    includeBuild 'build-logic'
}

rootProject.name = 'release-tools'```
```// build.gradle
tasks.named("check") {
  dependsOn(gradle.includedBuild("build-logic").task(":check"))
}```

```
// init script
gradle.taskGraph.whenReady { taskGraph -&gt;
    taskGraph.allTasks.each { Task task -&gt;

        println "INIT SCRIPT CONFIGURING " + task.project.rootProject.name + " :: " + task.path
    }
}```
then I get this output: <https://scans.gradle.com/s/vpyaw427spwau/console-log?anchor=25>

seems like something worth to raise a bug

I also tested with 7.5, but I think with a traditional included build, not within `pluginManagement`

There are some options but all of them will require to "stub" your engineering API at some point:
1. only call your engineering from `src/debug/kotlin/**` 
2. expose an interface that you load using a <https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html|ServiceLoader> or some other reflection technique (I think log4j does this)
3. expose different artifacts `engineering` , `engineering::noop`  (what you're currently doing)

You could also always call into `engineering` and use R8 to remove the calls in release builds, like you would remove calls to `Log.d`

1. I explicitly was trying to do something other than this because of the following case: I was loading a koin module from that `engineering` module with `loadKoinModules` exposing some <https://github.com/HedvigInsurance/android/blob/fc97661861cb807b686ec4193e0bf7a7c34d1252/hanalytics-engineering/src/main/java/com/hedvig/android/hanalytics/engineering/di/HAnalyticsEngineeringModule.kt#L15-L17|interface impls> which would then be taken and used <https://github.com/HedvigInsurance/android/blob/53c71229268694db590c7e39788ff9de71fbf879/hanalytics/src/main/java/com/hedvig/android/hanalytics/di/HanalyticsModule.kt#L40|here>, but this resulted in koin not loading those at the same time, so the things provided from `engineering` were not picked up in time:sweat_smile: So I wanted to move the engineering module in my main `startKoin{}` to load them at the same time like I now do <https://github.com/HedvigInsurance/android/blob/85c5945e9ef1a05d300f43c2db78f8688d1bf0ef/app/src/main/java/com/hedvig/app/feature/di/KoinInitializer.kt#L81|here>. So since that is called from scr/main I have to have access to it, and have it do nothing in prod. I asked about this <https://kotlinlang.slack.com/archives/C67HDJZ2N/p1659210532857339|here> to see if I could fix it on the koin part though.
2. Ngl this sounds like some magic, I don’t even know where I’d start with smth like that so I’m thinking I’ll skip if I got other options :smile:
3. Yeap, this is what I am doing right now.
4. The r8 option does sound very interesting, but could I then “remove” the entire module using r8? What about the call <https://github.com/HedvigInsurance/android/blob/85c5945e9ef1a05d300f43c2db78f8688d1bf0ef/app/src/main/java/com/hedvig/app/feature/di/KoinInitializer.kt#L81|here>, what would this then do :thinking_face: I understand with Log.d it can just not call it, but here since I’m constructing a list, how would r8 work to make this work? I’d guess it’d have to look somewhat different.

2. is basically doing 3 dependencies instead of 2:
• `engineering-api` is the one that you depend on in your app and defines an interface
• `engineering-impl` is the one you add to `"debugImplementation"` 
• `engineering-noop` is the one you add to `"releaseImplemenation"`
And then retrieve the implementation by reflection. This is not that different from 3 except that you get a bit more tooling because there is now a "contract" of what `"engineering-api"` is and IntelliJ will tell you what methods are missing in `"engineering-noop"` to satisfy the contract

&gt; since I’m constructing a list, how would r8 work to make this work?
Not super familiar with koin but I guess you could do this:
```val myModules = mutableListOf(
  ...
)
appenEngineeringModules(myModules)
modules(myModules)```
And remove `appendEngineeringModules` with R8

You could also register a different transform that modifies the bytecode with `asm` if you wanted to... Certainly a lot of trouble and will start to feel like magic to someone not familiar with the codebase though...

All in all, my favourite solution would be 2. Sure it's some boilerplate but it works well with the IDE and it's easy to understand

Yeah the asm idea feels like magic indeed, not quite familiar enough to try that I think.

The API approach does sound very nice indeed, the tooling and clear understandability wins sound like what I'd prefer.
I think I get all of what you're saying until you mentioned the reflection part. Do you have any sample in mind which does something like that which I could look into?

Because the `engineering-api`  module will be an interface, it will not have any constructor. The constructor is what you need to get by reflection.

I guess if you use the same name in both implementation, it'd work without reflection though

Reflection is useful if you want to allow loading implementations at runtime but looks like this is not your case as you'll have both implementations available at compile time