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

Gradle Community

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

Regarding the problem, please provide an <https://stackoverflow.com/help/mcve|MCVE>. What you provided works perfectly fine here:
```dep: DefaultExternalModuleDependency{group='org.openjfx', name='javafx-base', version='11.0.2', configuration='default'}
dep: DefaultExternalModuleDependency{group='com.github.ben-manes', name='gradle-versions-plugin', version='0.11.1', configuration='default'}```

Apologies, I was attempting to create a more readable case but ended up removing the issue entirely. I have now solved my issue, some info for the interested:

It seems the actual issue I was encountering was unrelated to dependencies, but instead with a change to the order in which gradle calls methods on extensions

This shouldn't make any difference generally, but in this case (likely due to poor implementation) it does. See this comment on github <https://github.com/openjfx/javafx-gradle-plugin/issues/140#issuecomment-1494730885>

Probably, find out why it is slow and make it faster. :slightly_smiling_face:
Maybe look at the `--info` or `--debug` logs to find out what is happening, or maybe use the `gradle-profiler`. (<https://github.com/gradle/gradle-profiler>)

If you want a copy that removes files not being present in the source you’d need to use the `Sync` task.

Basically always use `Sync` or `sync { ... }` unless you really want to "copy together" things with multiple actions / tasks. And then better don't do it anyway. :smile:

Use `app:assemble` instead of `app:build`? (and then `:app:test`, `:app:spotlessCheck`, etc.)

He's getting this execution from :build -&gt; :check -&gt; :spotlessKotlinCheck dependency chain, right?

That said, there's apparently a way to disable spotless as a dependency of the `check` task: <https://github.com/diffplug/spotless/tree/main/plugin-gradle#disabling-warnings-and-error-messages>

ooh. didn't know that build is assemble + check TIL

idiomatic approach is to use a convention plugin as appropriate.

Please you elaborate on that. Can config be shared across modules or not?

Yes, by using convention plugins as Chris said.

You could use `subprojects { ... }` too, yes, but you shouldn't.
It is bad practice by now and as it adds project coupling prevents some more sophisticated Gradle performance features like configure-on-demand or parallel configuration. Besides that it makes builds less clear to read and harder to maintain.

<https://docs.gradle.org/current/userguide/sharing_build_logic_between_subprojects.html#sec:convention_plugins>

For a quite complex example of which you do not need all parts for a small project: <https://github.com/jjohannes/idiomatic-gradle>

is there a good article on implementing convention plugins? we dont use them yet, but sharing a spotless config seems like a good first task for me and my team.

if you use precompiled plugin it is the same than configuring the spotless on a project, but in buildSrc or an included build, and apply that plugin

My takeaway from this is that sharing plugin config is possible, but complicated, so ideal config is not really worth chasing

With buildSrc is simple, but custom included build is not hard either 

It is simple either way, they are almost identical in effort.
And as Javi said, if you use precompiled script plugins for your convention plugins, you write them almost identical to build scripts.

Did you at all look at the convention plugins documentation link I gave you?

For smaller examples (shameless plugs): <https://github.com/tbroyer/auto-delegate> (uses buildSrc) and <https://github.com/tbroyer/javac-diagnostics-serializer> (uses an included build).
The `local.base` plugin sets up Spotless for the `*.gradle.kts`, the `local.java-library` applies `local.base` and sets up Spotless for Java code.
The root `build.gradle.kts` only applies `local.base`, whereas subprojects each apply the `local.java-library` plugin (and in javac-diagnostic-serializer, the gradle-plugin subproject also configures Spotless for Kotlin code)

Ok I think I got the idea behind convention plugins and I quite like it :slightly_smiling_face:

One follow up question - can convention plugin defined in the `buildSrc` use alias from version catalog rather hardcoded id string??

`buildSrc\src\main\kotlin\local.testplugin.gradle.kts`:

Does not work:
```plugins {
    alias(libs.plugins.spotless)
}```
Works:
```plugins {
    id("com.diffplug.spotless")
}```

No, unfortunately not.
For outside the `plugins { ... }` block there is a hack-around I created in the according feature request.
But within the `plugins { ... }` block it does not work.

I made most of this stuff work :slightly_smiling_face:

 I just have a single warning "The `embedded-kotlin` and `kotlin-dsl` plugins rely on features of Kotlin `1.8.10` that might work differently than in the requested version `1.8.20`." - any idea on how to solve this?

Kotlin-dsl uses the embedded Kotlin version (1.8.10) for plugin code.  This shouldn’t be mixed with say Kotlin(jvm) which is for application code.

Why don't you eliminate the need for the substitutions instead?

&gt; Why don’t you eliminate the need for the substitutions instead?
does gradle provide a function for their mechanism for this that we can use to guarantee that this to be the case? for example, how do I know that `com.mycompany.android.mysdk:yyy` will match `:xxx:yyy`?

&gt; Why don’t you eliminate the need for the substitutions instead?
also would be nice to retain the ability to have different module names than their folder structure

That's exactly the point.
Name the projects (modules) like the artifact name should be.
Then use the settings script to set the project directory to be whatever you like to have for it.
Then the composite build should work wihtout manual substitution I think.

I have some “sample” projects which contains a full build.gradle.kts (i.e. <https://github.com/2BAB/Caliper/tree/main/caliper-gradle-plugin/src/fixtures/android-test-sample>), however it does not link to current  project structure, thus no code highlight/completion still. I guess the idea plugin could potentially add it to the IDE recognition path and then maybe treat it as a standalone script to gain some highlight/completion features from IDE.

I think all approaches are valid depending on what you want to test and what you find easier to maintain. For what you ask, I have used these two approaches in the past:

1. There is a test runner library– <https://github.com/gradle/exemplar|Exemplar> – (also from Gradle) that you can use to test examples without writing test code at all
2. Write tests with Gradle's test kit, but load example builds from a folders as test data by copying them into a tmp folder in the test _setup()_
Example for 1:
<https://github.com/gradlex-org/java-ecosystem-capabilities/blob/main/src/test/java/org/gradlex/javaecosystem/capabilities/samples/SamplesTest.java>
<https://github.com/gradlex-org/java-ecosystem-capabilities/tree/main/samples/sample-all>

Example for 2:
<https://github.com/CodeIntelligenceTesting/cifuzz-gradle-plugin/blob/main/src/test/kotlin/com/code_intelligence/cifuzz/test/fixture/CIFuzzPluginTest.kt#L19-L23|https://github.com/CodeIntelligenceTesting/cifuzz-gradle-plugin/blob/main/src/test[…]n/com/code_intelligence/cifuzz/test/fixture/CIFuzzPluginTest.kt>
<https://github.com/CodeIntelligenceTesting/cifuzz-gradle-plugin/tree/main/examples/single-project>

I also find writing tests for Gradle plugins a real struggle. There doesn’t seem to be a nice way.

• Gradle TestKit is great, but lacks some functionality (like setting JVM memory), can be poor performing (too many logs causes OOM), and has some weird bugs (daemons sometimes don’t get killed). 
• Trying to apply my plugin in test projects can work using TestKit’s `withPluginClasspath()`… but that has flaws, and doesn’t test the plugin-marker. Trying to share my plugin via a local Maven repo is <https://www.linen.dev/s/gradle-community/t/10042069/hey-folks-i-though-i-was-going-to-nail-it-but-i-didn-t-i-hav#3aff1aa4-744f-4d72-8630-e59a20ed471a|really really not easy>.
• Using temporary dirs might be recommended, because re-using a directory means the tests aren’t consistent, but often I want to quickly have a look at the test project, and perhaps open it in an IDE, to check why it failed or what assertions I should write. It’s more difficult if it’s in an obscure temp dir.
• Personally I prefer writing test projects using raw-strings and using the `@Language` annotation so IntelliJ can help out <https://github.com/adamko-dev/dokkatoo/blob/693eeaa5900f77acb1fe7e9376d8fb3463fdd597/modules/dokkatoo-plugin/src/testFunctional/kotlin/MultiModuleFunctionalTest.kt#L445-L527|example>, but this isn’t great. It’s often really awkward editing the strings, and I don’t get the full power of auto-complete
• Writing gradle.kts fragments and merging them - <https://github.com/Kotlin/binary-compatibility-validator/blob/5d08f51f5f5e10a9cbfdb72956018fe833d0621b/src/functionalTest/kotlin/kotlinx/validation/test/SubprojectsWithPluginOnSubTests.kt#L34-L61|example> - the fragments aren’t loaded in IJ and don’t get auto-complete
• Using template projects (standalone examples) can work… but it’s awkward if I want to re-use an example but tweak some of the config
• I haven’t dug too much into using includedBuilds, because I keep overthinking it and I don’t want to get into a confusing mess of inter-dependent projects!
I’d love for the testing framework to be improved. I’ve been mulling over these ideas:

• publishing <https://github.com/adamko-dev/dokkatoo/blob/693eeaa5900f77acb1fe7e9376d8fb3463fdd597/modules/dokkatoo-plugin/src/testFixtures/kotlin/GradleTestKitUtils.kt|the DSL> I wrote for creating test projects (it’s nice for creating smaller sample project)
• helpers for managing copying template projects (Gradle’s sync task is really helpful, especially for find-and-replace, it’d be nice to have that available - can I inject Gradle services in my test classes?)
• generate the Kotlin DSL accessors for my plugin (and any others that I may want) that are unscoped and available in my test sources, and create some sort of ‘test project’ DSL that will - so I can fluently create a test project
• maybe some sort of specialised kotlin-dsl-test-fixtures source set, which has the `kotlin-dsl` plugin applied so I can write pre-compiled script plugins that would then be built and made available for use in my test projects?
• replace `withPluginClasspath()` with a Gradle task that will publish my plugin to a local Maven dir, and then my test-projects can load my plugin from that file-based repo. <https://github.com/adamko-dev/dev-publish-plugin/|I made a start on a plugin for this>, but it’s kind of buggy.

Not an easy one I think.
Would probably need something like writing an init plugin that does the iteration and then invoking the included build through tooling api or something like that.

Ok. It's only to allow excluding the included build when running its tasks (`:runTask` vs `:included-build:runTask`) so it's not really important but I was wondering if it was possible. Thanks for your answer

I suppose you could use a settings plugin to configure the version catalog (create another project with the plugin, `includeBuild` it in `pluginManagement` in your `settings.gradle.kts` and apply it; see <https://github.com/gradle/gradle>, and its build-logic-commons and build-logic-settings, used by the root project and build-logic)

It's indeed much easier with a TOML file, and I'd say that unless you have specific needs you should probably use a TOML file.

`from(files(../gradle/libs.versions.toml)`

I have seen that - I was wondering here if catalog defined in code can be somehow shared
```dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            version("kotlinVersion", "1.8.20")

            plugin("springframework-boot", "org.springframework.boot").version("3.0.5")```

maybe as extension function in another included build which could be consumed in both settings files?

too hard setup anyway, I would use toml file always, Kotlin just for overriding any version if necessary 

It depends on the situation.
TOML is very simple, intentionally.
For usual cases I'd also prefer it.
API is there for more sophisticated needs like having an own format that needs to be parsed, or things that need to be calculated, ...

I don't think you need a separate plugin.
You can just use the `distribution` plugin (that the `application` plugin applies and configures under the hood) to put your plugin and related jars wherever you need them in the final distribution.

Ah, right, that's probably enough. I keep forgetting about the distribution plugin. Thanks.

<https://discuss.gradle.org/t/how-do-you-attach-a-debugger-to-gradle-so-that-i-can-debug-it-running-a-task/7526> believe this answers your q. you can move the port where you want

I was under the impression that the debugger port is different than the daemon port

no worries, I had came across the same thing too yesterday when searching :laughing:

I believe this is where the port for the gradle daemon is set: <https://github.com/gradle/gradle/blob/0bd581a28013a7df9a9f7f8fe8230638aad812b1/subprojects/messaging/src/main/java/org/gradle/internal/remote/internal/inet/TcpIncomingConnector.java#L59|https://github.com/gradle/gradle/blob/0bd581a28013a7df9a9f7f8fe8230638aad812b1/sub[…]/gradle/internal/remote/internal/inet/TcpIncomingConnector.java>

and setting `0` will pick a random available port

that code above is entered from here, <https://github.com/gradle/gradle/blob/0bd581a28013a7df9a9f7f8fe8230638aad812b1/subprojects/launcher/src/main/java/org/gradle/launcher/daemon/server/DaemonTcpServerConnector.java#L51|https://github.com/gradle/gradle/blob/0bd581a28013a7df9a9f7f8fe8230638aad812b1/sub[…]org/gradle/launcher/daemon/server/DaemonTcpServerConnector.java>

```/**
 * Opens a TCP connection for clients to connect to communicate with a daemon.
 */```

oddly, I can't find any documentation or tutorials online of people setting up the IntelliJ Gradle Plugin to work over SSH. There is only a brief mention of it on this page: <https://www.jetbrains.com/help/idea/run-targets.html#supported-rcs>

that does surprise me. perhaps try extending the issue to android studio? it may have similar overlap on the issue

i feel like most people build locally then remotely debug, not both of those things

I did see more discussion online when it came to using the gradle debugger remotely -- barely anything for building remotely

:wave: Hey, <@U011F9DKGUU>! You can define a new JVM Test Suite for your integration tests. It will take care of creating the source sets for you. 

<https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html#sec:declare_an_additional_test_suite|https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html#sec:declare_an_additional_test_suite>

:wave: how do i pass new src dir? (would like to keep my integration tests in separate dir from unit tests)

:+1: had to scroll down a bit -&gt; example is provided in the linked doc

When you define a new test suite it will create a new source set for you and will be separate from any other existing tests.

You're welcome! With the JVM test suite plugin you should not need to worry about source sets at all. It will handle it for you.

Awesome! Yeah this looks much simpler than my current setup

And just for completeness, I guess this will work: `configure&lt;KotlinSourceSet&gt; { ... }`

:wave: Hey, <@U04NA0ETHCN>! I hope I understand your question correctly.

The recommendation would be to not reuse project directories between tests. 

In the documentation you linked, you can see that `@TempDir` is being used. This results in a new project directory for each test execution.

Give it a working directory that is transient so  that nothing is cached.  Or run with —no-build-cache

:wave: personally I'd recommend to use composite builds instead of gradle runner -&gt; it will be much faster

*well keep gradle runner it for failure scenarios and use composite build for happy path

oh yeah that's what I overlooked. looking at the sample code i have from gradle's site...i believe i stumbled on a docs bug (or perhaps used non-"current")...the code in the gradle samples i downloaded didn't use that feature. i'll try and track it down to file an issue for it - from `readme.md` :"link:zips/sample_gradle_plugin-kotlin-dsl.zip[icon:download[] Kotlin DSL]"
:samples-dir promote-projects/gradle/build/git-checkout/subprojects/docs/build/working/samples/install/gradle-plugin
:gradle-version: 8.0.1

<@U011F9DKGUU> yeah, I'm inclined to agree..., from what little I know of the process, but the testing facilities at the plugin creation testing stage seem to lead me down this path and kts docs aren't always where I look. I have much to learn on Gradle still. Structuring build structures around can be challenging in little "gotcha" ways sometimes

Diagram somewhat illustrating the project structure we have.

Enforced platforms have been added to ease Maven to Gradle transition, as the platform then behaves more like the Maven resolution mechanism.

It is however problematic and does not compose well as you have discovered.

The recommended way for achieving what you want is to embrace `strictly` constraints.
But this probably means copying Maven BOM content to a Gradle platform.

Thanks for your reply!

What would that solution mean when Software module 1 enforces version `1`, Software module 2 enforces version `2` , and Application 1 enforces version `3` (all through a Gradle platform)?

If I understand `strictly` constrains correctly, Gradle would not be able to resolve this automatically, or am I mistaken there?

When transitively including a Maven BOM with `enforcedPlatform` in a Gradle platform I believe these become `strictly` constraints. Copying the BOMs we use is not really a good option as we use some pretty extensive ones!

What is the recommended way to conditionally apply the plugin? I want to use it only for specific build variants in Android project

replace `id("org.gradle.kotlin.kotlin-dsl") version "3.2.6"` with

````kotlin-dsl````
(including the backticks)

xD fair, thanks :slightly_smiling_face: sorry for being trigger happy :wink:

&gt; The request for this plugin could not be satisfied because the plugin is already on the classpath
This is a long story…. but basically there’s probably 10 different ways to set the version of a Gradle plugin, and most of those can’t be used together - yes it’s confusing! Under the hood it’s related to classpaths and Gradle needs to have a consistent classpath…

Anyway, because you’re using buildSrc and you’ve defined the Kotlin Gradle plugin version in there (which is the correct thing to do), then this will enforce the Kotlin Gradle plugin version for the _whole_ project.

So, if you apply the Kotlin Gradle plugin anywhere else, then remove the version

```// ./subproject-foo/build.gradle.kts

plugins {
  kotlin("jvm") // version "..."
}```
and Gradle will pick up the version from `buildSrc/build.gradle.kts`

The implementation dependency in the buildSrc adds the Kotlin Gradle Plugin to the classpath of your build, so you now need to use version-less plugin IDs in your build: the version is now managed by the dependency in the buildSrc

Fwiw, I generally move all plugins as dependencies of the buildSrc (or equivalent included build); this basically replaces centralized version declaration in the pluginManagement in the settings.

<@U02KX5B7EVC> ah ok, I see, will do that then :slightly_smiling_face: what's the difference/reason for the backtick version of the kotlin-dsl, and why does ktor do it in the way I'm trying (tried to lean a bit on their config for inspiration :wink: )

<@UDC9Q9RD0> I will probably take some inspiration from that :wink: sounds like a good way

hmmm I’m not sure why Ktor uses the plugin ID and version for Kotlin DSL <https://github.com/ktorio/ktor/blob/b05dd2966b036d85179130af1abdc4ba8780ffa8/buildSrc/build.gradle.kts#L6>

Basically `kotlin-dsl` is a shortcut for applying the Kotlin DSL with a version that’s compatible with the _current_ Gradle version. You don’t _have_ to use the recommended version, but it’s wise. Maybe Ktor needed a newer version of Kotlin DSL, but couldn’t update Gradle?

if there's a recommended version, I will definitely go for that  - no reason to deviate (at least on the current level of development)

you should be able to ctrl+click on `kotlin-dsl` and it should take you to the source code, but it’s not working on my machine. I thought it was fixed… <https://github.com/gradle/gradle/issues/20995>

<@U02KX5B7EVC> <@UDC9Q9RD0> thanks again, things seem to be working like a charm now and it's looking really great :pray:

ah I managed to get IntelliJ to show the source code for `kotlin-dsl` (the newer IJ versions seems to skip auto-indexing the Gradle jars to improve startup)

So if you’re using Gradle 8 and manually applied Kotlin DSL version 3.2.6, then you’d be missing out :)

can you elaborate on that? i too have been bit by the versioning thing and specifying a custom nexus repo, trying to reduce the copypasta and inconsistencies. at this point, i'm not sure if i'm using a buildsrc build..i think i was able to switch to a composite build and have the conventions plugin be a `includeBuild`
<https://gradle-community.slack.com/archives/CAHSN3LDN/p1680685968225419?thread_ts=1680685390.572419&amp;cid=CAHSN3LDN>

There are many places where to define your plugin versions (and I'll limit this to the plugin DSL):
• use `plugins { id("plugin.id") version "plugin.version" apply false }` in the root `build.gradle`/`build.gradle.kts`
• use `pluginManagement { plugins { id("plugin.id") version "plugin.version" }` in the `settings.gradle`/`settings.gradle.kts`
• use dependencies in `buildSrc/build.gradle`/`buildSrc/build.gradle.kts` (or the `build.gradle`/`build.gradle.kts` of a build included with `pluginManagement { includeBuild("build-logic") }`)
The last one is the only way to get the plugins available in your precompiled script plugins (in the `buildSrc` or `"build-logic"` build), so I tend to declare all my plugin dependencies there and not use the others at all.

Fwiw, I also use version catalogs, so I actually declare the versions in the version catalog's TOML file, and then use those to actually declare the dependencies. I never use the `plugins { alias(…) }` (except actually in the `buildSrc/build.gradle.kts` or `build-logic/build.gradle.kts`)

Here's an example: <https://github.com/tbroyer/gradle-incap-helper/blob/main/build-logic/build.gradle.kts> (other relevant files: `settings.gradle.kts`, `build-logic/settings.gradle.kts` and of course `gradle/libs.versions.toml`)
(also note that I actually use all those plugins from precompiled script plugins, but it doesn't really matter: the included build will be added to build's classpath, so any plugin in its dependencies is available to the build)
This other example uses a `buildSrc` instead of an included build: <https://github.com/tbroyer/auto-delegate>

okay great, thank you that's helpful. the docs could really use improvement on clarity here, this breakdown you did would've been great to see on gradle's docs. there's a lot of "yeah do it this way it works fine ooooh you're using this well we didn't mention that but you need to do this                 a totally different way because you're using these types of builds"

there is a new doc page in the works for ‘how to write a plugin using Kotlin’

<https://github.com/gradle/gradle/pull/24286>

since you’re just starting out, I think it’d be really valuable if you read the proposal and gave your thoughts!

btw there’s usually not much difference between using buildSrc and included-build for convention plugins. I prefer using buildSrc because it’s a little bit simpler, but included-build can be really useful in some cases.

There used to be more differences between included builds and buildSrc, see the Gradle 8 release notes: <https://docs.gradle.org/current/release-notes.html#improvements-for-buildsrc-builds>

yeah, i noticed that 8 has made a lot of the gotchas less. makes me wonder, with parity so similar, what's the point of each at this point?

As this is a community Slack and you seek for help by Gradle in the context of your enterprise customership it might maybe make more sense to ask via your normal support channel. :slightly_smiling_face:

so you are saying for an enterprise customer we have a dedicated channel for communication with gradle?

No, I'm saying if you are a paying customer I guess you have some way to get support, called "support channel" as a generic term. I didn't mean Slack channel there :smile:

I just used a generic term as I have no idea concretely as I'm not a paying customer and not a Gradle employee, just a normal user. :slightly_smiling_face:

cool, thanks.  I will try getting some contacts. :thank_you:

Does it change anything if you do not use the internal class, but inject the `BuildEventsListenerRegistry` interface and use `onTaskCompletion` on it?

We used BuildEventListenerRegistryInternal, to take info about build stats.
To have a better idea, the code is more or less the same to this one:
<https://proandroiddev.com/gradle-configuration-caching-replacing-a-build-listener-with-build-services-40bde11937f1>

<https://github.com/jonnycaley/build-service-demonstration>

Too much code to read right now.
Which information do you miss from the public API?

Yeah, I understood, no idea which public API should use, we’re pretty new on Gradle Plugin development.

This was our first test and we take inspiration from the article to have build info and be configuration compatible.

I don’t know if there is a public BuildEventListener we’re we can access to build info

tldr: remove `alias(libs.plugins.kotlin.jvm)` from `buildSrc/build.gradle.kts`’s plugins block.

The `kotlin-dsl` plugin already applies the Kotlin plugin that’s embedded into Gradle. Applying the Kotlin plugin twice is probably going to be okay, but it might cause weird issues. So only apply `kotlin-dsl`.

you’ve mixed kotlin-dsl and kotlin-jvm plugins:
```alias(libs.plugins.kotlin.jvm)
    `kotlin-dsl````
That should never be the case.  `kotlin-dsl` is for building a gradle plugin (in Kotlin), `kotlin-jvm` is for your application code.

see <https://docs.gradle.org/current/userguide/kotlin_dsl.html#sec:kotlin-dsl_plugin|the Kotlin DSL plugin docs>

and these issues about the warning:

• <https://github.com/gradle/gradle/issues/16779>
• <https://github.com/gradle/gradle/issues/13020>
• <https://github.com/gradle/gradle/issues/20132>
• <https://github.com/gradle/gradle/issues/22647>


So I have removd `alias(libs.plugins.kotlin.jvm)`  from `build.gradle.kts` `plugins` block, but the warning is still there. After removing it from dependencies block my build fails as some of the custom conventions plugins are depending on `org.jetbrains.kotlin.jvm`

```&gt; Task :buildSrc:generatePrecompiledScriptPluginAccessors FAILED
4 actionable tasks: 3 executed, 1 up-to-date

FAILURE: Build failed with an exception.

* Where:
Precompiled script plugin '/Users/igorwojda/IdeaProjects/mango/buildSrc/src/main/kotlin/local.base.gradle.kts' line: 1

* What went wrong:
Plugin [id: 'org.jetbrains.kotlin.jvm'] was not found in any of the following sources:```


possibly applying this plugin `alias(libs.plugins.kotlin.plugin.jpa)` in buildSrc might also bring along the Kotlin JVM plugin

in fact, I think you can probably remove all plugins except for `kotlin-dsl` and the code-analysis plugins

```// buildSrc/build.gradle.kts

plugins {
    `kotlin-dsl`

    alias(libs.plugins.spotless)
    alias(libs.plugins.detekt)
}```

it’s possible the issue is wider-spread than just buildSrc/build.gradle.kts  - if there are precompiled script plugins that, by themselves or in conjunction with other plugins applied, also apply that combination of plugins `kotlin-dsl` and `kotlin("jvm")` .  Your buildSrc stuff should solely use `kotlin-dsl`.  Unless your convention plugins and the projects using them are also building plugins they should likely use `kotlin("jvm")`

Good tips I have cleaned up rest of the plugins and updated config.
Thx everyone for help

You should probably use a strict version instead: <https://docs.gradle.org/current/userguide/rich_versions.html>

But be aware that `sqldelight` then of course may fail to execute as it says it needs at least 1.8.0

the SQLDelight Gradle plugin shadows a _lot_ of dependencies, and IIRC it also includes the Kotlin Gradle plugin. That’s not an easy thing to work around…

<https://github.com/cashapp/sqldelight/issues/3644>

i was able to force it to 1.7.10, however, as you mentioned, this may cause issues w/ sqldelight so will proceed with caution. Thank you <@URQ797WRW> <@U02KX5B7EVC>

we have some gradle logic which builds docker images,

project b produces a base image for project a.

So use dependsOn gradle.includedBuild(....) to ensure the base image is built and available during the parent build when working in a composite build, the tag to use for the base image is then passed to a property of a custom task which builds parent image, this is currently hard coded.

I was just having a brainwave (or so i though) that if it could be picked up from the composite build somehow it would save the need to hardcode this, and as a result occasional change.

Easiest is possibly to write the info you need to a file in B and read the file in A

Maybe look at a thread dump to see if something is waiting on something or similar?

Well, then you probably need to investigate where the deadlock happens and why, or at least knit some reproducer. :slightly_smiling_face:

the signing plugin isn’t very lazy. Perhaps it’s proactively trying to contact the gpg agent and getting stuck?

Shouldn't be *that* eager though. :smile:

I would hope not but I wouldn’t be surprised :grimacing:

Is it safe to assume that you are on Gradle 5.3 or newer?

Then it should usually just work.
Is maybe something suspicious or enlightning logged on `--info` or `--debug` level?

Otherwise to debug, I guess a good starting point is `ExternalResourceResolver` where `metadataSources` is used.

Yeah, I checked the logs before, nothing interesting there and wanted to actually avoid debugging. But I debugged it eventually and it turned out gradle also cached the metadata. We just fixed our proxy server that previously wasn’t serving the `.module` files, so gradle resorted to regular POMs. But now when we fixed our proxy server gradle still had the old metadata cached locally and didn’t even try to resolve them again. Removing metadata caches from `.gradle` dir helped.

Great, or `--refresh-dependencies` would probably also have helped. :slightly_smiling_face:

I've found <https://github.com/gradle/gradle/blob/3aa8e82bc5dfff2b09748c7834240741dfb7558a/subprojects/testing-jvm/src/main/java/org/gradle/api/internal/tasks/testing/detection/DefaultTestExecuter.java>

Which kinda answers my question, it should be single instance of this executor across modules. right?

It is an option on a task of type `Test` and thus should only affect the task you set it on.

within same module? it should work by default 

my integration tests are failing complaining about accessing internal function

build -&gt; <https://github.com/dariuszkuc/graphql-kotlin/blob/graal_wip/plugins/server/graphql-kotlin-graalvm-metadata-generator/build.gradle.kts>

fails on internal reference -&gt; <https://github.com/dariuszkuc/graphql-kotlin/blob/graal_wip/plugins/server/graphql-kotlin-graalvm-metadata-generator/src/integrationTest/kotlin/com/expediagroup/graphql/plugin/graalvm/custom/GenerateGraalVmCustomScalarMetadataTest.kt#L55|https://github.com/dariuszkuc/graphql-kotlin/blob/graal_wip/plugins/server/graphql[…]lugin/graalvm/custom/GenerateGraalVmCustomScalarMetadataTest.kt>

so guessing that is what is causing the problem

I think you are referring to gradle internal APIs and not your own internal APIs right? In that case I don’t know 

nope that is my API -&gt; <https://github.com/dariuszkuc/graphql-kotlin/blob/graal_wip/plugins/server/graphql-kotlin-graalvm-metadata-generator/src/main/kotlin/com/expediagroup/graphql/plugin/graalvm/GenerateGraalVmMetadata.kt#L52|https://github.com/dariuszkuc/graphql-kotlin/blob/graal_wip/plugins/server/graphql[…]/expediagroup/graphql/plugin/graalvm/GenerateGraalVmMetadata.kt>

i could make it public as module will only be used from gradle/maven plugins but it feels wrong to open it up just for some tests

oh, Kotlin `internal` visibility? you just need to `associateWith` the compilation. IDE support isn't quite there yet though

i see, thanks for the info
found ~<https://youtrack.jetbrains.com/issue/KTIJ-7662/IDE-support-internal-visibility-introduced-by-associated-compilations>~

<https://youtrack.jetbrains.com/issue/KTIJ-23114/>

build a jar and use <https://github.com/lvc/japi-compliance-checker|https://github.com/lvc/japi-compliance-checker> or <https://github.com/Kotlin/binary-compatibility-validator|https://github.com/Kotlin/binary-compatibility-validator>? they do a bit more than you asked for though

<@U019L3NM4PK> Thanks for the suggestions. I chose the second one, exactly what I was looking for

Well, actually you can just check whether the extension is there, no need to check whether the plugin is applied

Except that has some additional meaning for your use-case

yeah I think I could just do
`val javaApplicationExtension = project._extensions_.findByType(JavaApplication::class._java_)`

Or of course you wire the main class property from the extension to a property of your task.

so I'm thinking about exposing the prop in my extension but specify default convention (that reads it from `JavaApplication`)

If your build is compatible with it, you don't mind that the feature is experimental, and you do not build on ephemeral agents or care to save and restore it, why not?

&gt; don’t mind that the feature is experimental
I believe it’s promoted to stable in 8.1 RC3, so as soon as the next release hits (matter of weeks?) this should not be an issue any more!

Thanks for the answer <@URQ797WRW>

&gt; and you do not build on ephemeral agents or care to save and restore it
Yes, this is the main reason for my question, we use ephemeral agents in our env, so before we spike it ourself, we want to know if anybody have tried it and got a good result.

Do you "want to resolve a toolchain" or do you need a JavaCompiler or JavaLauncher?

<https://docs.gradle.org/current/userguide/toolchains.html#sec:plugins>

Iterate through the dependencies and check for it's type to be `ProjectDependency` iirc

<https://docs.gradle.org/current/userguide/dependency_resolution.html#sec:programmatic_api>

something like this should be a start

```tasks.register("printSubprojectDependencies") {
  group = "help"

  val subprojectNames = configurations.compileClasspath.map { conf -&gt;
    conf
      .incoming
      .artifactView {
        componentFilter { it is ProjectComponentIdentifier }
      }.artifacts
      .artifacts
      .map { it.id.displayName }
  }

  inputs.property("subprojectNames", subprojectNames)

  doLast {
    logger.lifecycle(subprojectNames.get().joinToString())
  }
}```
but that only logs _incoming_ subproject dependencies. And it’s the compile-time only, but you can tweak it to also log the runtimeClasspath.



If

• `subproject-b` and `subproject-c` depend on `subproject-a`, 
• and you want a task _inside_ `subproject-a` that prints “I’m used by subproject-b and subproject-c” ,
then that might be a little more difficult. Subprojects aren’t supposed to know how other subprojects are configured.