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

Gradle Community

```Failed to notify build session lifecycle listener.
&gt; failed to access class org.gradle.workers.internal.WorkerDaemonClient from class org.gradle.workers.internal.WorkerDaemonClientsManager$StopSessionScopedWorkers (org.gradle.workers.internal.WorkerDaemonClient is in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @52a86356; org.gradle.workers.internal.WorkerDaemonClientsManager$StopSessionScopedWorkers is in unnamed module of loader org.gradle.initialization.MixInLegacyTypesClassLoader @27912e3)

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

* Exception is:
org.gradle.internal.event.ListenerNotificationException: Failed to notify build session lifecycle listener.
	at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:111)
	at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:69)
	at org.gradle.internal.event.DefaultListenerManager$EventBroadcast$ListenerDispatch.dispatch(DefaultListenerManager.java:443)
	at org.gradle.internal.event.DefaultListenerManager$EventBroadcast$ListenerDispatch.dispatch(DefaultListenerManager.java:431)
	at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:43)
	at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:66)
	at org.gradle.internal.event.DefaultListenerManager$EventBroadcast$ListenerDispatch.dispatch(DefaultListenerManager.java:443)
	at org.gradle.internal.event.DefaultListenerManager$EventBroadcast.dispatch(DefaultListenerManager.java:232)
	at org.gradle.internal.event.DefaultListenerManager$EventBroadcast.dispatch(DefaultListenerManager.java:203)
	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
	at jdk.proxy1/jdk.proxy1.$Proxy18.beforeComplete(Unknown Source)
	at org.gradle.internal.session.DefaultBuildSessionContext.execute(DefaultBuildSessionContext.java:48)
	at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter$ActionImpl.apply(BuildSessionLifecycleBuildActionExecuter.java:100)
	at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter$ActionImpl.apply(BuildSessionLifecycleBuildActionExecuter.java:88)
	at org.gradle.internal.session.BuildSessionState.run(BuildSessionState.java:69)
	at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter.execute(BuildSessionLifecycleBuildActionExecuter.java:62)
	at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter.execute(BuildSessionLifecycleBuildActionExecuter.java:41)
	at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:64)
	at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:32)
	at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:50)
	at org.gradle.tooling.internal.provider.SessionFailureReportingActionExecuter.execute(SessionFailureReportingActionExecuter.java:38)
	at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:47)
	at org.gradle.tooling.internal.provider.SetupLoggingActionExecuter.execute(SetupLoggingActionExecuter.java:31)
	at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:65)
	at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:39)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:29)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:35)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:78)
	at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.create(ForwardClientInput.java:75)
	at org.gradle.util.internal.Swapper.swap(Swapper.java:38)
	at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:75)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:64)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:63)
	at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:84)
	at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:37)
	at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:104)
	at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:52)
	at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:297)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:49)
Caused by: java.lang.IllegalAccessError: failed to access class org.gradle.workers.internal.WorkerDaemonClient from class org.gradle.workers.internal.WorkerDaemonClientsManager$StopSessionScopedWorkers (org.gradle.workers.internal.WorkerDaemonClient is in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @52a86356; org.gradle.workers.internal.WorkerDaemonClientsManager$StopSessionScopedWorkers is in unnamed module of loader org.gradle.initialization.MixInLegacyTypesClassLoader @27912e3)
	at org.gradle.workers.internal.WorkerDaemonClientsManager$StopSessionScopedWorkers.beforeComplete(WorkerDaemonClientsManager.java:187)
	at jdk.internal.reflect.GeneratedMethodAccessor51.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.event.DefaultListenerManager$ListenerDetails.dispatch(DefaultListenerManager.java:472)
	at org.gradle.internal.event.DefaultListenerManager$ListenerDetails.dispatch(DefaultListenerManager.java:454)
	at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:83)
	at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:69)
	at org.gradle.internal.event.DefaultListenerManager$EventBroadcast$ListenerDispatch.dispatch(DefaultListenerManager.java:443)
	at org.gradle.internal.event.DefaultListenerManager$EventBroadcast$ListenerDispatch.dispatch(DefaultListenerManager.java:431)
	at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:43)
	at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:66)
	at org.gradle.internal.event.DefaultListenerManager$EventBroadcast$ListenerDispatch.dispatch(DefaultListenerManager.java:443)
	at org.gradle.internal.event.DefaultListenerManager$EventBroadcast.dispatch(DefaultListenerManager.java:232)
	at org.gradle.internal.event.DefaultListenerManager$EventBroadcast.dispatch(DefaultListenerManager.java:203)
	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
	at jdk.proxy1/jdk.proxy1.$Proxy18.beforeComplete(Unknown Source)
	at org.gradle.internal.session.DefaultBuildSessionContext.execute(DefaultBuildSessionContext.java:48)
	at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter$ActionImpl.apply(BuildSessionLifecycleBuildActionExecuter.java:100)
	at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter$ActionImpl.apply(BuildSessionLifecycleBuildActionExecuter.java:88)
	at org.gradle.internal.session.BuildSessionState.run(BuildSessionState.java:69)
	at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter.execute(BuildSessionLifecycleBuildActionExecuter.java:62)
	at org.gradle.tooling.internal.provider.BuildSessionLifecycleBuildActionExecuter.execute(BuildSessionLifecycleBuildActionExecuter.java:41)
	at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:64)
	at org.gradle.tooling.internal.provider.StartParamsValidatingActionExecuter.execute(StartParamsValidatingActionExecuter.java:32)
...```

I assume there is no daemon running if you say "longer time". Do you maybe now use a different and maybe incompatible JDK?

For context I’m using `--platform=linux/amd64 gradle:8.1.1-jdk11` as my base container. I’ve tried all of the different file sharing impls (gRPC fuse, Virtio and osxfs) but none work. The gradle daemon just runs the build over and over because its unable to watch the files

It’s worth noting I’m running x86 containers using Rosetta and part of the conatiner in using a bind mount onto my local fs

Can you provide an <https://stackoverflow.com/help/mcve|MCVE> with a "wiring like that", that shows the problem?

unsupported class file version 63 indicates you are running Gradle (or some tool within) with an older Java version - upgrade to at least Java 18 (class file version 63).

as noted, yes, something in your build is depending on at least that version of Java.

Nope.  Some component of that build is using pre-Java 18, hence the incompatibility.  Unfamiliar with Android builds, you’ll have to track down which component is the problem.

So then, I have to DOWNgrade, my java version?

There is some component of the build that requires at least Java 18 but is using &lt; Java 18 - track that down and adjust accordingly.

try running Gradle with --debug and start by analyzing the output.

&gt; There is some component of the build that requires at least Java 18 but is using &lt; Java 18 - track that down and adjust accordingly.
Nope, it is him running Gradle 7.2 with Java 19 which is not supported.

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

Either use a newer Gradle version or an older - compatible - Java version to run it.

Im working with a team. If I upgrade gradle, it will affect all the branches of the repo? or is it something like only local for me?

If the project is sane, it contains the Gradle wrapper, so it will be for everyone.

so. in my case, it would be better to downgrade my java version?

The Gradle wrapper defines with which Gradle version a project is built so that there can be no incompatiblities due to different versions like in Maven.

&gt; so. in my case, it would be better to downgrade my java version?
How should we know?
It is (almost) always good to update to latest versions.
But if you don't want to, then yes you need to downgrade your Java.

yes, but as you said, upgrading Gradle could affect all the other branches if I do a git push...

where as I assume grading my java version locally on my laptop, won't affect anybody else but me

that's why I mean it would be better to downgrade my java

Ok I've downgraded my JAVA version. Now let's see if this works

It will not affect other branches. It affects wherever you push it. If you only push it in one branch it only affects that branch like with any other code change.

But yeah, to only affect you, use a compatible Java version

yes of course, what I want is to not affect anybody else

I have no idea what's causing this problem

using internal APIs,
```val taskNames = objects.domainObjectSet(String::class)
tasks.withGroovyBuilder {
    "whenElementKnown" {
        taskNames.add(getProperty("name") as String)
    }
}
taskNames.all {
    println("$path:$this registered")
    tasks.named(this) {
        println("$path:$name configured")
    }
}```
seems to work for me, but no promises

Should work I think.
Maybe there was a hickup, try again with `--refresh-dependencies` if it still does not work, make sure you do not need some proxy to access external system or similar and that you do not have a firewall or antivirus that interferes.

Maybe as dependency in `buildSrc`?
`buildSrc` is yet again a special beast and not part of the conflict resolution etc., so in that case you might fix it by using a composite build instead.

Well, then I cannot guess anymore without seeing your build or an <https://stackoverflow.com/help/mcve|MCVE> that demonstrates the problem.

`settings.gradle.kts`
```rootProject.name = "spinnaker-teamcity-build-plugin"

rootDir.listFiles()?.forEach {
  if(it.isDirectory &amp;&amp; it.name.startsWith("teamcity-build") &amp;&amp; it.list()?.contains("build.gradle.kts") == true) {
    include(it.name)
  }
}

dependencyResolutionManagement {
  repositories {
    mavenCentral()
  }
}```
`build.gradle.kts`
```@Suppress("DSL_SCOPE_VIOLATION")
plugins {
  alias(libs.plugins.spinnaker.plugin.bundler)
  alias(libs.plugins.palantir.git)
}

spinnakerBundle {
  pluginId = "DoubleCloud.TeamCityBuildPlugin"
  description = "Provide TeamCity Builds access and logs from Spinnaker Deck"
  provider = "<https://github.com/mazzy89>"
  version = rootProject.version.toString()
}

version = normalizedVersion()

subprojects {
  group = "cloud.double.spinnaker.plugin.teamcity.build"
  version = rootProject.version.toString()
}

fun normalizedVersion(): String {
  val gitVersion: groovy.lang.Closure&lt;String&gt; by extra

  val fullVersion: String = gitVersion()
  val normalized: String = fullVersion.split("-").first()

  return if (fullVersion.contains("dirty")) {
    "$normalized-SNAPSHOT"
  } else {
    normalized
  }
}```

and the subproject
```@Suppress("DSL_SCOPE_VIOLATION")
plugins {
  alias(libs.plugins.kotlin.jvm)
  alias(libs.plugins.kotlin.kapt)
  alias(libs.plugins.spinnaker.plugin.serviceextension)

  id("maven-publish")
}

kotlin {}

spinnakerPlugin {
  serviceName = "igor"
  pluginClass = "cloud.double.spinnaker.plugin.teamcity.build.TeamCityBuildPlugin"
  requires    = "igor&gt;=0.0.0"
}

dependencies {}```

sorry do not follow you. more minimal than this i cannot go. i do not have any other files :smile:

The problem is not the M, but the C :wink:

I'm just a user like you and am right now too lazy to try building a project from those pastes that then maybe still has a slight difference.

If you want me to have a quick look to maybe see the problem, please provide a complete MCVE as zip or GitHub project or Gist or whatever. :wink:

sure. let me point you to the gh project so there should be there all the tree structure

<https://github.com/mazzy89/spinnaker-teamcity-build-plugin/tree/first-release>

I'm not sure why it says the version cannot be checked.
Maybe worth a bug report.
As work-around, add the plugins with `apply false` to the root build script, then it works.

So I would need to define all the plugins st the root build script and set Apply false and then defined them again in the plugin block in the subproject did I get it right?

Yes, the one in the root project just adds it to the class path and the one in subproject then actually applies it

going to try thanks Vampire a lot. and then i will fill a bug report

But I'm using special custom sign plugin, which doesn't do signing itself, just provide setup and custom signing mechanism implementation for the default Gradle signing support. And this plugin using old Gradle version to build. And now how Gradle works internally. I would tell that if I running this plugin on 8.1.1 is should simply use all code from Gradle 8.1.1 and fact, that it is build with older Gradle should not be relevant not?

This isn’t a “fixed in Gradle” issue - somewhere in your build scripts (or that plugin) the configuration is referencing the project, which is not CC compatible.

you’ll need to check with the plugin author as to whether that plugin is CC compatible.

So I will try also this plugin update to latest Gradle a try to build it myself.

to be clear - if a plugin is not CC compatible upgrading the Gradle version won’t help that.  The plugin code needs to be adjusted.

Yes. if plugin definine some task in wrong way (not compatible with CC) it is obvious for me.
But in the error was not a task from this custom plugin, but `org.gradle.plugins.signing.Sign`
Which confusing me.

it could be in code that configures that plugin, either in your build script or another plugin.

And one more question.
What if this custom plugin actually using one another X plugin which is not compatible
But mine project also using this X plugin in the new version which is already compatible.
Does it mean that Gradle will use only the latest version of X plugin.
Or will load and use both of them?

To my knowledge the plugins go through dependency resolution which will, by default, pick the latest version.  That may be problematic for the ‘other’ plugin if things are no longer compatible.

OK. I already found, that issue is really caused by custom plugin setuping signing, it doesn't declare any task, but extend `org.gradle.plugins.signing.signatory.SignatorySupport` class which is then used by Gradle itself inside of `org.gradle.plugins.signing.Sign`

yes, looks like that AvastSigningExtension is the culprit.

You are trying to run Gradle 7.0.2 with Java 17 which is not supported. Either upgrade Gradle or downgrade the Java version with which you run it to a supported version: <https://docs.gradle.org/current/userguide/compatibility.html>

I don't think Gradle does anything to restrict this, so I'd think the test jvms have access to all CPU cores.

I'm definitely seeing Runtime.getRuntime().availableProcessors() return one, and all the thread pools get configured accordingly, so if it's not Gradle I don't know who's doing it

Does Gradle itself has access to more cores?

Or are you maybe running Gradle in some Docker container that restricts the available CPUs or similar?

And since Gradle likes to fork a bunch of jvms to run test, it makes sense that it would want to restrict each jvm to 1 core

I don't think that would make sense and I'd really wonder if Gradle did, especially by default.
I'm not even aware of an option to restrict that in Java itself without using some OS feature from outside.

But let me quickly test, while you do the other test I asked about :wink:

&gt; `Runtime.getRuntime().availableProcessors() = 8`

found it.

org.gradle.jvmargs=-Xmx1g -XX:TieredStopAtLevel=1 -XX:+UseParallelGC -XX:ActiveProcessorCount=1 \

oh yea that will do it.  best to leave that option out, the JVM will detect the available cores in the container/server.

Ah, well, an XX option you set yourself, well yeah, then that explains it. :smile:

an XX option from a project with hundreds of other contributors, yes

Didn't mean "you" like "you personally" but like "your project".
Sorry if it came across badly. :slightly_smiling_face:

Did you refresh the Gradle project?
Does it also error when building from command-line?
If yes, can you share a build `--scan`?

<https://scans.gradle.com/s/mmeqqtmybcwtu/dependencies?dependencies=code-scanner&amp;expandAll>

Are you sure you added it to `implementation`, not `runtimeOnly`?

Hm, actually there is no compile classpath in the report

Ah, ok, it doesn't even come to compilation

<https://scans.gradle.com/s/mmeqqtmybcwtu/console-log?page=1#L27>

&gt; ```:app:processDebugMainManifest FAILED
&gt; [code-scanner-2.1.0.aar] C:\Users\VYSHNAV\.gradle\caches\transforms-3\5a8a0677368d58ddbdd88b12937e6b24\transformed\code-scanner-2.1.0\AndroidManifest.xml Warning:
&gt; 	Namespace 'com.budiyev.android.codescanner' used in: code-scanner-2.1.0.aar, com.github.yuriy-budiyev:code-scanner:2.3.2.
&gt; C:\Users\VYSHNAV\AndroidStudioProjects\Login\app\src\main\AndroidManifest.xml Error:
&gt; 	uses-sdk:minSdkVersion 23 cannot be smaller than version 24 declared in library [:qrcodelibrary] C:\Users\VYSHNAV\AndroidStudioProjects\Login\qrcodelibrary\build\intermediates\merged_manifest\debug\AndroidManifest.xml as the library might be using APIs not available in 23
&gt; 	Suggestion: use a compatible library with a minSdk of at most 23,
&gt; 		or increase this project's minSdk version to at least 24,
&gt; 		or use tools:overrideLibrary="com.example.qrcodelibrary" to force usage (may lead to runtime failures)```


That would also be my guess, that you set the version to snapshot version after that plugin is applied.
I usually set the version in the `gradle.properties` file, then I have no such problems.

what workaround can i use here? my problem is that i am using the axion-release-plugin, so it is the thing that resolves the version dynamically(i don't use that just yet, it's hardcoded). so that would not work with the gradle.properties

trying to make it so that as much as is possible, is contained within the convention plugin. not going to be nice to have to dupe that publishing repository block for 100 applications...

<@UDC9Q9RD0> i recall you working on and had some nuances you shared about convention plugins. have you also run into this issue?

If the `axion-release` plugin calculates this version on being applied, make sure it is applied before that plugin, or actually apply it in that plugin before using the calculated version.
I - personally - would say don't use it, as I hate dynamically calculated versions that depend on the version control being present.
This prevents proper reproducible and VCS independent builds. You cannot build a source export, you cannot build in a Git worktree if JGit is used for Git access, .....
Other than that, you can of course use the good old - but very bad - `afterEvaluate { ... }` so that eventually the version was maybe already set.

I hear your points, though they seem too theoretical for my use, whereas what I am sick of is versions in code, auto merge\release merges, developers having to think about versions (when in reality they don't matter for many apps). And triggering releases off of git tags seems to be pretty common these days

Aside from that, the simplistic problem is: if I add in a plugin, a calculation on the repo based on version, then when I apply the plugin, it's not recalculating that version...I guess. 

Just a basic functionality that I would expect to be able to achieve for publishing, someone else must have encountered that before or fixed it.. Because it's a pretty basic use for a convention plugin 

The irony is that maven does this easily

It's also common that people build fat jars.
Doesn't make them any less an abuse of Java functionality and major bad practice with man pitfalls that could easily be circumvented by not doing that non-sense. :smile:

possibly; but it's debatable and there's pros/cons

Regardless, even without that concept, i still should be able to get the plugin to just listen to what i'm telling it to in the project. and deploy the thing to the right snapshot vs release url. it is a tricky issue to search for too

Well, as I said, you probably have to use `afterEvaluate` and cross fingers. :slightly_smiling_face:

okay i'll give it a shot.

sometimes...gradle perplexes me. it's like it all seems good sometimes and then you get 1 requirement that other toolchains handle just fine and it falls off the rails, no examples and workarounds only. the kind of thing where im' asking "uhh..did..nobody actually test this?". anyone converting a maven project should've hit that issue

Au contraire, I think JetPack is exactly the problem.
JetPack is broken by design for "normal" publishing and should imho never be used for such a use-case.
It should at most be used for ad-hoc testing specific commits or branches and even then there are often preferable options.
Besides that it is broken by design, it is slow, might fool the build tool, and unreliable.
It behaves even worse in case of multi-project builds.
And besides that, it also manipulates the generated Metadata after it was generated, and often does it in a bad way, especially with Gradle Module Metadata.
As you can see, it replaced the coordinates of the main artifact, but not the ones for additional variants like the test fixtures and thereby breaks the whole metadata.

Oh. Guess I should finally move to Maven Central then

Thanks for replying, once again. Do you know if GitHub Packages has issues like this?

Definitely. :slightly_smiling_face:
Setting this up is just a one-time half-pain for the long-time win and convenience of your users. :slightly_smiling_face:

GitHub Packages has the issue that noone outside GitHub Actions can really use it, because you can only access it authenticated.

So you need to feed your build with an access token to be able to resolve the dependencies.

It is a blessing that they forced authentication. Otherwise we'd see in the Java world an explosion of private repos, typo squatting and such. This would be terrible for security (and performance of resolution, and reproducibility, etc.). Publishing to Central isn't that hard. A bit of administrative work in the beginning, but then you're done.

Iirc with something like
```configurations.implementation {
    dependencies.addLater(...)
}```
or maybe with
```configurations.implementation {
    dependencies.whenObjectAdded(...)
}```


Ok whenObjectAdded and addLater are part of DomainObjectCollection, will try to remember that for the future.

Ah, no, what you want is
```configurations.implementation {
    withDependencies { 
        ...       
    }
}```

<https://www.linen.dev/s/gradle-community/t/9561104/i-want-to-write-a-plugin-that-can-issue-deprecation-warnings#2df63f83-003e-47cb-9d76-32096c6ff2d7>
&gt; `withDependencies` directly checks what is declared and also allows you to add additional dependencies "lat minute" (i.e. right before the dependency resolution starts). This is what it was mainly introduced for.

`file` in your code is actually `this@allPublishableArtifacts._file`, so it has a reference to_ `this@allPublishableArtifacts` which then cascades.
Store `file` to a local variable outside the `doLast` and I think it should be compatible.

For the second trace, I'd guess it is either `api` or `config`, but you didn't specify what those are.

Btw. why do you get the publication by name, when you alread have it in `this`?

And `project.plugins` should not be used, according to its JavaDoc, but instead `project.pluginManger.withPlugin("maven-publish") { ... }`. Especially `withType` does not make too much sense as a plugin cannot be applied multiple times.

Yes! Using copy of File outside of `doLast` decreased amount of errors to 6.

Thanks to
```project.pluginManager.withPlugin("maven-publish")```
I just don't like the string constant instead of class name, but it is probably safer.

&gt;  Btw. why do you get the publication by name, when you alread have it in `this`?
Hard to say, it is 2 years old code :slightly_smiling_face:
I probably wanted to make it clear, because there is too much this, I like more when there is lambda parameter instead of this.
But yes I can use proper `this@all`

&gt; I just don't like the string constant instead of class name, but it is probably safer.
Yeah, well, whatever works for you. Just saying it is not the recommended way. :slightly_smiling_face:

You can use `this@all`, or you can do `all publication@*{` and then* `this@publication`, or you can do `val publication = this` right after the opening brace and then use `publication` later.

And rest of 6 issues.
the config has reference to
```project.providers```


Or
```also { publication -&gt;

}```
or
```let { publication -&gt;

}```

Yeah, well if `config` has reference to `project` and as you have `config` in `doLast`, you have your last break point. :slightly_smiling_face:

Not directly to project, but to providers, it is allowed to use them in Task, but probably only via

```@get:Inject
abstract val providers: ProviderFactory```

Well, hard to say without seeing its code :slightly_smiling_face:

Hmm, it looks that this did not help, it still failing on 6 issues.
It looks like issue is that lambda itself has reference to enclosing class.

I know where is problem :slightly_smiling_face:

`api` and `config` are fields of enclosing class

So, issue is just in the color :slightly_smiling_face:
This is wrong

Thanks a lot. Solution is always so easy, why I always spent whole day on it :slightly_smiling_face:

Well, like with everything, it's just easy if you know the solution already. :smile:

Yes :slightly_smiling_face:


And reference to
```project.providers```
 is completely fine. I can keep it there and it still works.

The second is a Gradle bug and can be ignored. For the first check what was logged before, and if info is not sufficient follow the advices in the end.

<@URQ797WRW> Thank you for your reply. It says to try the Run command with multiple options like --stacktrace, --info, --debug, and --scan. Where exactly should I be running this command? Through my VS Code terminal?

The advice is for command-line usage, I have no idea how to do it with VSC. If I want a fancy editor, I use jEdit, if I want an IDE I use a real IDE. :slightly_smiling_face:

yeah esp with vscode...it's just not an IDE, and it shows that. that and the jvm ecosystem support is much worse right now

Nvm I just needed to read the scan, I was too focused on providing info that I didn't even look into it myself

```Corrupt serialized resolution result. Cannot find selected module (270) for releaseVariantReleaseRuntimePublication -&gt; org.jetbrains.kotlinx:kotlinx-coroutines-android:1.6.1```
Looks like this is the issue, but what is the resolution strategy here?

I can wipe away my `~/.gradle` folder but that's extremely nuclear and doesn't solve this for CI nodes.

Should we try upgrading this version?

Ok so I'm mad confused, but this error popped up for a few members of my team and I thought it would be a fire, then it mysteriously went away. Safe to ignore this post!

`apply false` in the settings script is actually pointless. In the settings script you anyway just define default versions for plugins but do not apply it anywhere. Building the subproject should work fine. Hard to say what the problem is without more information or an MCVE.

Besides that, I would instead recommend using a version catalog instead of defining the version in the settings script.

Is a version catalog preferred over Convention Plugins?

I adapted my project from the gradle init multi-module project but was always running into issues using the Convention Plugins as the Kotlin JVM target is always set to 20 despite my attempts to change it to 1.8. So the convention files are still present but unused.

I wouldn't say preferred, as they are completely separate things. You typically use them both.

I'll look over the gradle init project more closely as it doesn't have the errors I'm hitting. Although I do have to set apply false in my settings.gradle.kts or I get a build exception. It does look to try applying the plugin to the parent project.

```An exception occurred applying plugin request [id: 'org.jetbrains.kotlin.jvm', version: '1.8.10']
&gt; Failed to apply plugin 'org.jetbrains.kotlin.jvm'.```

I see some discrepancies between what the gradle init wrapper uses for version and jvm, along with what is in my project wrapper, and what is just the gradle on my path. So I guess that gives me another thing to investigate.

Okay yes, I think the issue is using the wrapper script the jvm is set to 20. The Gradle version just on my path is jvm = 17, and that works to build the sub-modules without error.

&gt; Although I do have to set apply false in my settings.gradle.kts or I get a build exception.
Oh, you have it in top-level
```plugins {
    ...
}```
then I guess.
I assumed it is in
```pluginManagement {
    plugins {
        ...
    }
}```
where it belongs to define a default version if no version catalog is used.

e.g: `foo = { module = "foo:bar", version = "" }`

I ve just tried it and got `Reason: Version reference for 'firebase-database' must not be empty.`

version reference? Did you write `version.ref` instead of `version`?

ooops! You are absolutely right... Soz. I ve replaced `version.ref` with `version` and it worked! Thank you very much :slightly_smiling_face:

it’s also possible to omit the `version` reference entirely:
```awssdk-bom = { module = "software.amazon.awssdk:bom", version = "2.20.51" }
awssdk-core = { module = "software.amazon.awssdk:aws-core" }
awssdk-auth = { module = "software.amazon.awssdk:auth" }
awssdk-sts = { module = "software.amazon.awssdk:sts" }
awssdk-s3 = { module = "software.amazon.awssdk:s3" }
awssdk-sso = { module = "software.amazon.awssdk:sso" }```

It is not unfortunately.
Unless you provide an own implementation for the log message handling and then are completely responsible for the logging.
But a simple config file to configure certain log levels is unfortunately not supported.

Thanks that was my suspicion. Was hoping to be able to drop a logger.properties or similar and have Gradle look at it.  I did quickly look into creating my own Logger, but it didn’t seem strait forward to be able to handle all the incoming messages. Back to the drawing board I guess.

Works fine here.
In case it was a temporary hickup, try again, eventually with `--refresh-dependencies` in case Gradle remembers it didn't find it.
If it still does not work, double-check you do not have some firewall, virus scanner, proxy, or similar intervening.

I suspect the latter, especially as the IP from your message is some Indian IP, not one of the official IPs for `<http://raw.githubusercontent.com|raw.githubusercontent.com>`.

Hi, is there a way to autoprovision JDK 21 EA release via toolchain feature? I see that foojay api has this release, but build fails with:
```No compatible toolchains found for request specification: {languageVersion=21, vendor=any, implementation=vendor-specific} (auto-detect true, auto-download true).```

You should not use `mavenLocal` if possible or at most with using a repository content filter, because `mavenLocal` is broken by design.

Better use a composite build.

To get the "as close as possible to the experience as simply writing a `build.gradle` file" write your convention plugins as precompiled script plugins as documented at <https://docs.gradle.org/current/userguide/custom_plugins.html#sec:precompiled_plugins>

Unfortunately this just leaves me with more questions than answers, I'd already read this

I've created the minimal sample repos/files above with the hope that someone might be able to suggest a few lines of code which demonstrates it - a Github repo like this is exactly what I would have hoped for from the docs

Composite builds do not seem appropriate as it appears they require the "common" repo to be checked out locally already, which may be out-of-date

I'm curious as to what you mean by "mavenLocal is broken by design" - wonder if that contributes to any of my problems so far.

&gt; I've created the minimal sample repos/files above with the hope that someone might be able to suggest a few lines of code which demonstrates it
Those repos are not accessible, actually.
&gt; a Github repo like this is exactly what I would have hoped for from the docs
<https://github.com/jjohannes/idiomatic-gradle> might be interesting for you, but it might also be way more complex than you actually need and want.
&gt; as it appears they require the "common" repo to be checked out locally already,
Yes, that's correct.
&gt; which may be out-of-date
Well actually it is usally the other way around.
By requiring to manually publish the dependency to some repository or local repository or `mavenLocal()`, you always have to go to that module, change something, publish it manually and then use the new version.
With a composite build you can just change something in `common` and run the consumer build which will automatically build and use the dependency.
Both have their pros and cons liek always of course, but usually a composite build is much more convenient to work with, at least while developing changes.
&gt; I'm curious as to what you mean by "mavenLocal is broken by design" - wonder if that contributes to any of my problems so far.
Here are some of the problems documented: <https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:case-for-maven-local>

Silly me, the repos are visible now :slightly_smiling_face:

I am fine with a published module, I would have CI in place to publish any changes to a registry upon changes

My proposal for mavenLocal is literally just for simplicity in this PoC

None of those mavenLocal complaints provide any immediate problems for this PoC, it appears

Just to get a sense of complexity, looking at those repos, and (temporarily) using mavenLocal, how long do you think it would take to achieve that functionality?  Are we talking ~2 mins?

Soul-crushing if so, given the time I've spent on this: but promising still

But yeah, given all of my previous failed experimentation, this is pretty much my last-ditch effort.  Nobody in the org has managed to do this, so this is the decider as to whether we can continue to use Gradle, or bow to pressure from others who want to switch it out with an alternative :shrug:

A prohibitive limitation of "precompiled script plugins", it seems - it forces you to put the dependency versions in the depending projects (e.g. app1) - I'm looking for that to be completely abstracted away within the common module (not very DRY at all, otherwise)

&gt; A prohibitive limitation of "precompiled script plugins", it seems - it forces you to put the dependency versions in the depending projects
No, why should it?
Believe me, precompiled script plugins is exactly what you want.
And yes, it is more like a 2 minute effort.
You basically apply the plugin for the DSL you want to use and configure the publishing using `maven-publish`.
Then you can write your convention plugins almost like normal build scripts.

```Invalid plugin request [id: 'com.diffplug.spotless', version: '6.18.0']. Plugin requests from precompiled scripts must not include a version number. Please remove the version from the offending request and make sure the module containing the requested plugin 'com.diffplug.spotless' is an implementation dependency```
I got it working by specifying the dependency in the main project referencing the buildSrc as a plugin - which would lead me to think the same would be needed in a multi-repo setup.

That is one of the "*almost* like normal build scripts" points.
In the precompiled script plugin you use it without version.
You can define the version in the consuming project, but that's not the idiomatic way.
It is an implementation dependency of your convention plugin.
So you declare it as implementation dependency in the build script for your convention plugin, so in `common/build.gradle(.kts)`

```buildscript {
  repositories {
    maven {
      url "<https://plugins.gradle.org/m2/>"
    }
  }
  dependencies {
    classpath "com.diffplug.spotless:spotless-plugin-gradle:6.18.0"
  }
}```
This is what I had in the main project, but `buildscript` is not allowed in Groovy script plugins.  I'm sure there's another way to express it (I've tried multiple)

Have a look at Jendrik's repository I linked you to.
As I said, it is most likely more complex than you need it, and it uses composite builds,
but whether you use the project as composite build or publish it to a repository does not make much difference, except for the `maven-publish` configuration to actually publish it. The actual implementation and usage is the same.

I did already take a look, you're certainly right about it being too complex for me

&gt; This is what I had in the main project, but `buildscript` is not allowed in Groovy script plugins.  I'm sure there's another way to express it (I've tried multiple)
Well, you maybe didn't read what I wrote two message ago :slightly_smiling_face:

&gt; *Vampire*  [15:22 Uhr]
&gt; That is one of the "*almost* like normal build scripts" points.
&gt; In the precompiled script plugin you use it without version.
&gt; You can define the version in the consuming project, but that's not the idiomatic way.
&gt; It is an implementation dependency of your convention plugin.
&gt; So you declare it as implementation dependency in the build script for your convention plugin, so in `common/build.gradle(.kts)`

Definitely did, maybe just not understanding it.

No, you said you tried to add it to the `buildscript` block of the precompiled script plugin.
That is not even similar to what I said. :wink:

&gt;  So you declare it as implementation dependency in the build script for your convention plugin
I'm sure I'm just stupid, but this reads to me like the same thing.  Unwrapping the `buildscript` block also yields `org.gradle.api.plugins.UnknownPluginException: Plugin with id 'com.diffplug.spotless' not found.`

No, "the build script or the project building your convention plugin"
is not nearly the same as "the `buildscript` block inside your convention plugin".

I even told you the exact file where you put and what you put in there to make sure you don't misunderstand like that. :wink:

So does that not equate to the following?
```repositories {
    maven {
        url "<https://plugins.gradle.org/m2/>"
    }
}

dependencies {
    classpath "com.diffplug.spotless:spotless-plugin-gradle:6.18.0"
}```
``````

Um, and putting the version in there is what seems to the same as propagating it to clients to me.

I'm clearly too confused for this, thank you very much for your support

As this will give you "configuration classpath not found" and I said "implementation dependency", not "classpath dependency", no :slightly_smiling_face:

&gt; is what seems to the same as propagating it to clients to me.
Why?
It is part of the convention plugin build.
The consuming project will not need to specify the version anywhere.

I'll leave this thread in case anybody feels free to hack on the git repos I spent some time preparing (seeing as it sounds like a ~2 min task to demonstrate) - unfortunately I've done so much reading of documentation, examples, and conversations, that everything just feels like disconnected advice at this point.  Seeing a minimally working example is the only path forward to integrating my understanding at this point

Not sure what the problem is.
Take your last code block, replace `classpath` by `implementation`, put that to the `common/build.gradle(.kts)` build script, then use the plugin without version in your convention plugin, that's it.

Added the changes: <https://github.com/ndg-github/common/blob/main/build.gradle>
```&gt; Failed to apply plugin 'common'.
   &gt; org.gradle.api.plugins.UnknownPluginException: Plugin with id 'com.diffplug.spotless' not found.```


That's because you nested your plugin too deep.
By having `common/buildSrc` you have yet another standalone build that is built separately to then by applied in `common/build.gradle` which is not what you actually want.
You want your `common.gradle` in `src/main/groovy` and apply `groovy-gradle-plugin` in `common/build.gradle`.
Then you can apply `common` in your `appX` builds.

Besides that `common` is a bad name, custom convention plugins should always have some namespace (a dot in the name, or a package declaration in the precompiled script plugins). Namespaceless plugin IDs should be reserved for Gradle built-in plugins.

Thanks, yes, `common` was just quickly picked for the purposes of this PoC - not what I would keep.

So I've moved the apply of `groovy-gradle-plugin` into the `common/build.gradle` (well, `/build.gradle`, being the repo root)

Are you saying to `mv buildSrc/src/main/groovy/common.gradle src/main/groovy/common.gradle` essentially?

Doing that yields `Plugin [id: 'common'] was not found in any of the following sources:`

Yes I do and you of course remove applying `common` in `common/build.gradle` (just using `common/` to make sure I'm not talking about `appX/build.gradle`).
You want to apply `common` in `appX/build.gradle`, not in `common/build.gradle`.

You cannot apply to the build building `common` the result of building `common`. That would be a hen-and-egg situation.

That makes sense to me now.  I've explored enough bad routes that I've lost sense of good and bad

Just imagine `common` as a standalone version of `buildSrc`, which actually is exactly the case.
So basically if you copy `buildSrc` out, rename it to `common` and add publishing configuration you are almost where you want to be.

Okay, so I've published to mavenLocal (<https://github.com/ndg-github/common/blob/main/build.gradle>)

And a failed access from: <https://github.com/ndg-github/app1/blob/main/build.gradle>

Now I'm not surprised it is failing to find the plugin, but I'm not quite sure on what the solution needs to look like

I'm assuming I need a `gradlePlugin` of some sort in `common/build.gradle`; and perhaps something else in `app1/build.gradle`

I'm attempting something, but can't remember the name of the function that yields the gradle plugin repo URL

No, `common` is fine, you just did not specify the version of `common`to apply in `app1`

If it is not coming from an included build / composite build, but from a repository, you have to specify a version.

Added that separately since my last message;

I'm thinking I need something like this in `app1/settings.gradle`:
```pluginManagement {
    repositories {
        mavenLocal()
    }
}```
Except also including the gradle plugin repo

But additionally the version for the plugin

So many permutations of Google searches didn't turn that up.  Maybe one that should have gone to GPT :smile:

`gradlePluginPortal()` is the default if you have nothing, but if you have anything you have to be explicit

Yup, I'm glad to be thinking of something correctly

So this leaves me with a new error message, which is progress:

```Execution failed for task ':tasks'.
&gt; Could not create task ':spotlessJava'.
   &gt; Could not resolve all files for configuration ':spotless865456303'.
      &gt; Cannot resolve external dependency com.google.googlejavaformat:google-java-format:1.16.0 because no repositories are defined.
        Required by:
            project :```

ChatGPT is not helpful anyway.
It is good for giving answer that *look* nice and correct, but not for answer that *are* correct.
It is not for nothing that answers from ChatGPT are banned from being posted on StackOverflow for example.

ChatGPT is only good for things you could actually do yourself but are too lazy (the good lazy, not the bad one) as you have to undertand what he produced and need to fix the non-sense it put in.
I've yet to see a helpful programming solution by it except for the most trival things.
All I've seen so far was bullshit and with methods on APIs that never existed and so on.
Besidest that its data base is more than 2 years old, so ancient in computer terms, especially for a rapid evolving thing like Gradle.

&gt; ```Cannot resolve external dependency com.google.googlejavaformat:google-java-format:1.16.0 because no repositories are defined.```
That most probably is because you have no repositories for `app1`.
So either add it there or to your convention plugin.

Believe me, I never talk to GPT in areas I have technical competence in.  I did say this was a last-ditch effort :wink:

I'm following along as I'm in a very similar boat trying to fix up a multi-module project that started life as several individual projects and I've smooshed together into a monorepo.

The worst part about wrong ChatGPT answers is that it answers as if it's entirely sure it is correct, where at least a person would have the sense to say they don't know.

And GPT even failed for that.  I was thinking it was a sufficiently narrow-scoped question.  The key word to know is "portal".. forget that, and you're not finding it

Sweet Jesus it worked.  Thank you for getting me there <@URQ797WRW>

To go with that github repo for idiomatic gradle, he also has a playlist going over a ton of stuff.

<https://www.youtube.com/playlist?list=PLWQK2ZdV4Yl2k2OmC_gsjDpdIBTN0qqkE>

I just have to be honest, for some reason I find Gradle docs (and online resources) rather impenetrable.  I can't think of any other software technology where I've felt that way

If you don't mind letting me know when you push your changes ndg. I'm looking over the idiomatic-gradle but it's like jumping into the deep end.

Yeah that's pushed now <@U055B1Z6GG2> :+1:

<@URQ797WRW> - last question for now before I leave my computer, and then re-look at again this with fresh eyes :slightly_smiling_face:

You mentioned best-practice, that plugins should have dots in their name; in this case the plugin is using `rootProject.name`

1. Would you suggest changing `rootProject.name` to `foo.common`; or another route without changing the `rootProject.name` itself?
2. I used a group ID of `com.example` for the artifact - should the plugin name therefore conventionally be `com.example.common` ?

I'm not entirely sure what you mean by `rootProject.name` exactly here.
But yeah, if you put your plugin in group `com.example`, having `com.example.common` or `com.example.build.common` or whatever surely sounds sensible.