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

Gradle Community

You can share IntelliJ run configurations, just check the `Store as project file` checkbox in the run configuration popup.
But a custom task is also possible of course :slightly_smiling_face:

Do you really need an extra task, given that you always want to add those arguments? Can't you just set the args on the existing `app:run` task?

Thanks Niels, but just so I learn more about Gradle I would _really_ like to do it in Gradle.

How can I set the args on app:run in Gradle?

```tasks.run {
    jvmArgs(...)
    args(...)
}```


if gradle doesn't provide the accessor automatically, you can also use `tasks.named("run")`

Ok, great! And now for the "chrome plating"" Let's say I have 3 or more environments that I might want to connect to so I'd like to have 3 (or more) parameterized version of app:run pre-defined?

Maybe have a look at Jetbrains' idea-ext Gradle plugin?
<https://github.com/JetBrains/gradle-idea-ext-plugin/wiki#runConfigurations>

Also, tasks..run deosn't let me set args and jvmArgs

Thanks Thomas, I'll definitely check out that plugin!

yeah, you'll need `tasks.named("run")`, as `tasks.run` is "captured" by kotlin stdlib

pure `tasks.run` in Kotlin DSL does not work.
It will not use the task accessor but the standard Kotlin `run` extension function.
You need to use `tasks.named&lt;JavaExec&gt;("run") { ... }` or `tasks.run.configure { ... }`, or `import kotlin.run as run_` (or any other name).
See <https://www.linen.dev/s/gradle-community/t/2699183/how-can-i-add-an-enviroment-variable-to-the-gradle-run-task->

`tasks.named("run")` is not enough, as you then only get `Task` to configure

Thanks Vampire, that explains why I couldn't get it to work. will try accordingly. Any suggestions on how to define more than one parameterization of the app:run? Any idea why application suports defining default jvm argumetns but not application arguments?

Probably because it does not make too much sense, because application arguments are to be supplied by the caller of that application.

To have multiple parametrizations, you can either make the parametrization depending on some project properties or similar, if it is enough to call one task in one Gradle run.

Alternatively do not configure the standard `run` task, but properly register additional `JavaExec` tasks

Then you can also run them in the same Gradle invocation

That is what I started out trying to do... But I always stumble on it not finding the javafx modules that app:run manages to find. I even  tried looking at ApplicationPlugin.java to see what it does in addRunTask to do the same in my task definition. But it is not clear to me how to translate what it does with getModularity (which I assume where it gets the two javafx modules that I define with the help of the gluon plugin) to my kotlin task definition.  I was hoping they'd be in the configuration runtimeClasspath but they are not. They are in the Gradle local repo and somehow app:run finds them but I have not figured out how to point my task to them

You can see my best attempt in the intial post

That's most probably because JavaFX has a complete non-sense module-structure and does not work properly outside of Maven.
That's why you need the special JavaFX Gradle plugin that mitigates the non-sense they made there.
Could well be that it cares about fixing up the standard `run` task too and you need to do the same separately, not sure.
Maybe if you could knit an <https://stackoverflow.com/help/mcve|MCVE> "someone" could throw an eye on it.

Thank you to everybody that answered, especially Vampire. I got it to work for one configuration/target environment with:
_tasks_._named_&lt;JavaExec&gt;("run") *{*
    args("--engine", "<rmi://taurus:1100/PKSE>")
    jvmArgs("-Djava.util.logging.config.file=logging.properties")
*}*

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

try replacing

```  from(swiftSources)  ```
with

```  from(swiftSources.map { it.incoming.files })```
or, if `swiftSources` isn’t in a `Provider&lt;&gt;`:

```  from(swiftSources.incoming.files)```


Thanks for the suggestion, but unfortunately that did not help.
Even if I comment out the consumer task and depenencies the issue occurs.
Seems to be triggered at the producer side, when adding the artifact

ah I see, on the producer side, I missed that. You could try adding the outgoing files like this:

```swiftSources {
  outgoing {
    artifacts(tasks.updateDokkatooExamples.map { it.outputs.files })
  }
}```
(something like that anyway, I might have the wrong syntax)

Trying this now (in producer):
```val generateSwiftSources = tasks.register("generateSwiftSources") {
    dependsOn("metadataCommonMainClasses")
    val fileTree = layout.buildDirectory.asFileTree.matching {
        include("**/*.swift")
    }
    outputs.files(fileTree)
}


val swiftSources by configurations.creating {
    isCanBeConsumed = true
    isCanBeResolved = false
    outgoing {
        artifacts {
            add("swiftSources", generateSwiftSources.map { it.outputs.files })
        }
    }
}```
And getting:
```&gt; Cannot convert the provided notation to a File or URI: task 'generateSwiftSources' output files.
     The following types/formats are supported:
       - A String or CharSequence path, for example 'src/main/java' or '/usr/include'.
       - A String or CharSequence URI, for example 'file:/usr/include'.
       - A File instance.
       - A Path instance.
       - A Directory instance.
       - A RegularFile instance.
       - A URI or URL instance.
       - A TextResource instance.```

At least it is a different error :upside_down_face:

I decided to get rid of the filetree usage and use a Copy task to gather all files I want in a intermediate build dir:
(producer)
```val copySwiftSources = tasks.register&lt;Copy&gt;("copySwiftSources") {
    dependsOn("metadataCommonMainClasses")
    from(layout.buildDirectory.dir("generated/ksp/metadata/commonMain/resources"))
    include("**/*.swift")
    into(layout.buildDirectory.dir("swift"))
}


val swiftSources by configurations.creating {
    isCanBeConsumed = true
    isCanBeResolved = false
}


artifacts {
    add("swiftSources", copySwiftSources)
}```
This actually works fine for me :slightly_smiling_face:
Thanks for the help. Why the other approach did not work is still a mystery to me

ah good idea, yes a dedicated task definitely helps

btw you might want to use Sync instead of Copy. I always prefer using Sync because it will clear out any old files, so if a file is deleted from the source then Sync makes sure that will be deleted in the destination too

gradle does have custom handling of URL, <https://github.com/gradle/gradle/blob/master/subprojects/configuration-cache/src/main/kotlin/org/gradle/configurationcache/serialization/codecs/UrlCodec.kt>

maybe that only affects configuration cache and not normal task caching?

At a minimum, it's a known issue that you shouldn't use `java.net.URL` as a key in a hashmap because it does name resolution: <https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/URL.html#equals(java.lang.Object)>
So use a `URI` instead.

yeah, and that's part of the reason behind the stupid `networkaddress.cache.ttl=-1` default on some JVMs - otherwise `URL` equality may change over time :grimacing:

I don't think configuration cache is enabled there. I'll dig

I mean, maybe the code I linked only fixes URL serialization for configuration cache

The `URL` in question is nested in other objects, would that change anything?

Ah yea, if it's only for configuration cache then it doesn't help the case at hand

Looks like it's a general thing, opened <https://github.com/gradle/gradle/issues/24979>

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

build file -&gt; <https://github.com/dariuszkuc/graphql-kotlin/blob/graalvmSpring/integration/graalvm/spring-graalvm-server/build.gradle.kts>

it looks like it is something from spring

why spring? that's almost certainly a plugin/buildscript classpath issue

A build scan will most probably immediately uncover the culprit. :wink:

<https://scans.gradle.com/s/563sla66d6ld6>

graalvm plugin in multiple different projects buildscript classpathes may be the problem, they're all different classes

try adding it to the root project (apply false) or buildSrc dependencies

yeah it looks like i cannot use composite build :disappointed:

applying plugin (false) in root project seems to fix the issue

you'd need to do that with the kotlin gradle plugin too, if it weren't already in your buildSrc

Hm, is `GraalVMReachabilityMetadataService$Inject` something Gradle adds with the runtime decorations? It is not there in the plugins jar

I believe that Gradle defines that class to override `getParameters()`

isn't that how all the other similar injections via abstract fun work?

Maybe, never noticed which classes it generates probably. :smile:

ah, `org.gradle.internal.instantiation.generator.AsmBackedClassGenerator.decorateAndInject()` generates `$Decorated`, `org.gradle.internal.instantiation.generator.AsmBackedClassGenerator.injectOnly()` generates `$Inject`

Not really, because it is not a Gradle question.
Your application fails to execute so the Gradle task fails.
Debug your application to see why it does not behave as you expect.
Maybe you also have some error message already, but are struck by IntelliJ selecting the most specific node, so select a higher node on the left to see the earlier output.

4:03:56 PM: Executing ':AppRunner.main() --stacktrace'...

&gt; Task :compileJava NO-SOURCE
&gt; Task :compileGroovy UP-TO-DATE
&gt; Task :processResources UP-TO-DATE
&gt; Task :classes UP-TO-DATE

&gt; Task :AppRunner.main()
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.vmplugin.v7.Java7$1 (file:/C:/Users/bnadiku/.gradle/caches/modules-2/files-2.1/org.codehaus.groovy/groovy/2.5.6/6936e700f0fb1b50bac0698ada4347a769d40199/groovy-2.5.6.jar) to constructor java.lang.invoke.MethodHandles$Lookup(java.lang.Class,int)
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.vmplugin.v7.Java7$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

&gt; Task :AppRunner.main() FAILED
3 actionable tasks: 1 executed, 2 up-to-date

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':AppRunner.main()'.
&gt; Process 'command 'C:/Program Files/Eclipse Adoptium/jdk-11.0.18.10-hotspot/bin/java.exe'' finished with non-zero exit value 1

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

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':AppRunner.main()'.
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:207)
	at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:263)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:205)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:186)
	at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:114)
	at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
	at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:62)
	at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
	at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
	at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:409)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$CallableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:399)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:157)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:242)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:150)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:94)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.call(DelegatingBuildOperationExecutor.java:36)
	at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
	at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:41)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:356)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:343)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:336)
	at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:322)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182)
	at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: org.gradle.process.internal.ExecException: Process 'command 'C:/Program Files/Eclipse Adoptium/jdk-11.0.18.10-hotspot/bin/java.exe'' finished with non-zero exit value 1
	at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:417)
	at org.gradle.process.internal.DefaultJavaExecAction.execute(DefaultJavaExecAction.java:42)
	at org.gradle.api.tasks.JavaExec.exec(JavaExec.java:158)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:49)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:42)
	at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:28)
	at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:726)
	at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:693)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$3.run(ExecuteActionsTaskExecuter.java:569)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:395)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:387)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor$1.execute(DefaultBuildOperationExecutor.java:157)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:242)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:150)
	at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:84)
	at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:554)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:537)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.access$300(ExecuteActionsTaskExecuter.java:108)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.executeWithPreviousOutputFiles(ExecuteActionsTaskExecuter.java:278)
	at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.execute(ExecuteActionsTaskExecuter.java:267)
	at org.gradle.internal.execution.steps.ExecuteStep.lambda$execute$1(ExecuteStep.java:33)
	at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:33)
	at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:26)
	at org.gradle.internal.execution.steps.CleanupOutputsStep.execute(CleanupOutputsStep.java:67)
	at org.gradle.internal.execution.steps.CleanupOutputsStep.execute(CleanupOutputsStep.java:36)
	at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:49)
	at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:34)
	at org.gradle.internal.execution.steps.CancelExecutionStep.execute(CancelExecutionStep.java:43)
	at org.gradle.internal.execution.steps.TimeoutStep.executeWithoutTimeout(TimeoutStep.java:73)
	at org.gradle.internal.execution.steps.TimeoutStep.execute(TimeoutStep.java:54)
	at org.gradle.internal.execution.steps.CatchExceptionStep.execute(CatchExceptionStep.java:34)
	at org.gradle.internal.execution.steps.CreateOutputsStep.execute(CreateOutputsStep.java:44)
	at org.gradle.internal.execution.steps.SnapshotOutputsStep.execute(SnapshotOutputsStep.java:54)
	at org.gradle.internal.execution.steps.SnapshotOutputsStep.execute(SnapshotOutputsStep.java:38)
	at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:49)
	at org.gradle.internal.execution.steps.CacheStep.executeWithoutCache(CacheStep.java:159)
	at org.gradle.internal.execution.steps.CacheStep.execute(CacheStep.java:72)
	at org.gradle.internal.execution.steps.CacheStep.execute(CacheStep.java:43)
	at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:44)
	at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:33)
	at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:38)
	at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:24)
	at org.gradle.internal.execution.steps.SkipUpToDateStep.executeBecause(SkipUpToDateStep.java:92)
	at org.gradle.internal.execution.steps.SkipUpToDateStep.lambda$execute$0(SkipUpToDateStep.java:85)
	at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:55)
	at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:39)
	at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:76)
	at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:37)
	at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:36)
	at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:26)
	at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:94)
	at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:49)
	at
...............................org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:78)
org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:150)
org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:336)
org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182)
org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)


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

BUILD FAILED in 5s
4:04:02 PM: Execution finished ':AppRunner.main() --stacktrace'.

This is full error message . where am i missing the HIGHER LEFT NODE of application log?

Nowhere. Your application just does not output what the problem is. But still, this is not a Gradle topic, so this community is the wrong place. Your application is exciting with exit code 1 and die to that the Gradle task is failing.b debug your application to find out what the problem is, or add proper error output.

It seems the issue is with spring-boot's bootRun task generating a very long classpath argument to java.exe on Windows.

<https://github.com/spring-projects/spring-boot/issues/17766>

Why do you think this is spring-boot related, or related to that ticket <@U02DGQN2WL9>?
The name `:AppRunner.main()` should mean that this is a task generated by IntelliJ to run method `main()` in class `AppRunner`.
And it does not fail to start, it exits with exit code 1.

I debugged this a bit with Balanna and feel strongly that it’s related to spring. IIRC we (Gradle) had a recent update to create a classpath manifest jar automatically for JavaExec task types. Balanna is using Gradle 6.x, so I’m not sure if it includes that logic. Then again, this is spring-boot’s custom `bootRun` task. You are correct that `:AppRunner.main()` is an IJ Spring Configuration; I encouraged Balanna to delegate to Gradle’s `bootRun` task instead (with the same result; java.exe returns non-zero).

Unfortunately `--info` logging didn’t help other than emitting the full javaexec command (which has a very long `-cp` argument). This is almost certainly the same-old “classpath too long” issue.

I don’t know why this logic wouldn’t be taking effect though: <https://github.com/gradle/gradle/pull/10544>

Ah, ok, thx. Really wondered how you got to that assumption just from the infos provided here. :-D

Additionally, adding a full number in front
```implementation("com.mycompany", "mylib", "1.release-125")```
then we can get gradle to throw a resolution error
```&gt; Could not find com.mycompany:my-lib:1.release-125.```

Are there different resolution/failure rules for when an version is number formatted vs alphabetically formatted?

<https://docs.gradle.org/current/userguide/single_versions.html#version_ordering>

although what you have is an empty base version with a `release-*` qualifier, which is quite confusing

actually I'm not sure if that's how it's parsed, hmm

Gradle does not interpret versions as semver.
In that version `release` is the "major" version and `125` and `87` are the "minor" versions.
It just splits versions at `.`, `-`,  `_`, and `+` and additonally at the change between non-numeric and numeric, then the parts are compared.
So `release-87` &lt; `release-124` &lt; `release-125`

That 87 is picked when 125 is also requested, or that 125 is picked if 124 is requested and 125 not at all both make little sense to me and would need an <https://stackoverflow.com/help/mcve|MCVE>

missing-dep-resolution.zip

```gradle mylib1:pTML mylib2:pTML```
will create 2 publications (published to ~/.m2)
these will have 2 versions of the same artifact (release-124 and release-87)

run `gradle :myconsumer:run` to see the output

change the dependency version and the other jar will be picked up.

If that setup is comparable to your setup, I guess you have other problems.
You should not have two projects that produce the same artifact coordinates.
And if the consumer is in the same build too, I think the published artifacts are not used anyway, but the project dependencies directly.

This in no way mirrors our setup, other than our versions being named `release-&lt;build-number&gt;`

And us being confused about the resolution rules wrt
```// why is release-125 completely ignored
implementation("com.mycompany", "mylib", "release-125")
implementation("com.mycompany", "mylib", "release-87")```

Basically `myconsumer` is the only part comparable to our setup. If you change `release-125` to `1.release-125` (for example) it’ll throw a dependency resolution error.

Actually, right away this does not make much sense to me and I'd tend to say it is a bug.

It seems, that at least for local directory repositories non-existing versions are ignored which seems to be wrong

This is reproducible in remote repositories as well (I’ve verified release-125 is absent in our artifactory instance)

Hm, I guess it is too late for me to think properly, maybe <@U019L3NM4PK> is fit enough to see more

<@URQ797WRW> I appreciate your insight and help.

For a start, do not use `target.plugins`, have a look at its (`getPlugins()`) JavaDoc.

Besides that, if you develop a convention plugin, the you specify your dependencies and their versions in the build script of the project building those convention plugins. So specifying the plugin as `implementation` dependency in the build building the plugin and then applying it in your convention plugin is practically the same as your second snippet.

great, thank you, that works!

also can you elaborate why I should not use `target.plugins` ?

i am using Kotlin to develop my plugins, and in kotlin `target.getPlugins()` and `target.plugins` are the same. in fact i am getting a warning that i should use property access syntax instead of the getter method…

I know they are the same. I said read its JavaDoc where it tells you not to use it. :wink:

What you want to use is `target.apply(...)`

oh, i missed that, thanks!

so it’s
```class KotlinConventionPlugin : Plugin&lt;Project&gt; {
    override fun apply(target: Project) {
        target.apply {
            it.plugin("org.jetbrains.kotlin.jvm")
        }
    }
}```

`target._apply_(plugin = "org.jetbrains.kotlin.jvm")`

oh, so many options to do the same thing… :slightly_smiling_face:

thanks!

oh wait, this does not compile…
```class KotlinConventionPlugin : Plugin&lt;Project&gt; {
    override fun apply(target: Project) {
        target.apply(plugin = "org.jetbrains.kotlin.jvm")
    }
}```
what am i doing wrong?

Might be from the `gradleKotlinDsl()` that you might want to add as dependency to `compileOnly` and maybe `testImplementation`. Or you could apply the `kotlin-dsl` plugin which also does a few other things.

`kotlin-dsl` applies `java-gradle-plugin`, `kotlin-dsl.base`, and `kotlin-dsl.precompiled-script-plugins` plugins
`kotlin-dsl.base` plugin applies `embedded-kotlin`, adds `gradleKotlinDsl()` to the dependencies of `compileOnly` and `testImplementation` configurations, and configures the Kotlin DSL compiler plugins for example for proper SAM conversion for `Action` and similar.

Whatever you will try.
You must not change the configuration of another task (or own) at exexution time, no matter how you reference it, or it is CC incompatible, fullstop. :slightly_smiling_face:

If that 3rd Party task needs a `String`, you need to calculate that string at configuration time.

Even if it were a `Property&lt;String&gt;`, it would be calculated at configuration time, as provider values of tasks are realized and written to configuration cache when storing the CC entry afair.

Interesting. I was expecting that all @Input @Output fields of task are not serialized and are handled just before execution. Because this is stuff that is not the same. I mean I will change source code in my project, configuration cache should be still without change, but compile task will have a different input.

Ah sorry I read it badly, you are talking about providers no content itself

But then it is OK, when 3rd party taks will have Property&lt;String&gt;
I can simply  do this, even without extra task

```3rdPartyTaskProvider.configure {
    inputText.set(project.providers.fileContents(xyz).getAstext())
}```


&gt;  If that 3rd Party task needs a `String`, you need to calculate that string at configuration time.
And this is allowed?
It basically depend just on the setup inside of build.gradle file.
I mean this input string.
So it can be serialized inside of configuration cache.

But disadvantage is that this task is called only for production builds, so currently it is called very rare.
Filling it in configuration time mean, that it  will be prepared every time.

Why? If you leverage task-configuration avoidance, it will just be done when the task is going to be executed

Ahh, inside `configure {}` , yes this should work.

It looks that it works. Why I was trying to do it in such complicated way, when it is so simple.

the Configurations are created here: <https://github.com/adamko-dev/dokkatoo/blob/2e9fde349bfc5a0933d2758e9be137e08fbb3957/modules/dokkatoo-plugin/src/main/kotlin/formats/DokkatooFormatPlugin.kt#L204-L361>


If I have 3 subprojects:

```Root project 'dokkatoo-example'
   +--- Project ':childA'
   +--- Project ':childB'
   \--- Project ':docs'   (depends on :childA and :childB) ```
Each subproject needs to provide the following files:

• `./build/dokka-module/&lt;format&gt;/...` - a module directory
• `&lt;format&gt;-module-descriptor.json` - a single configuration file
• Dokka Plugins classpath - JAR files were used to build the subproject’s `dokka-module/&lt;format&gt;`
I’ve created a Configuration (resolvable=false,consumed=true) for each of the above.

And then `:docs` has resolvable Configurations in order to execute the Dokka Generator task

• all `dokka-module/&lt;format&gt;`s from other subprojects
• all `&lt;format&gt;-module-descriptor.json` files from other subprojects
• Dokka Plugins classpath
• Dokka Plugins, without transitive dependencies
• Dokka Generator classpath (which is Dokka Plugins + Dokka Generator)
All of these extendFrom() a base `dokkatoo` Configuration, so actually in the build script it’s succinct.

```plugins {
  id("dev.adamko.dokkatoo")
}

dependencies {
  dokkatoo(projects(":childA"))
  dokkatoo(projects(":childB"))
}```

However, every Configuration is specific per format. There are 4 output formats at the moment (HTML, Javadoc, Jekyll, Markdown), so there are 4 times as many incoming and outgoing Configurations.

You could maybe have one configuration and then work with the artifact type to get the artifacts you need currently. But just guessing here, didn't try that yet.

hmmm maybe, but I’m wary about using artifactType because it’s not well documented and I’d be concerned that it might interfere with selecting JARs

possibly a lot of the consuming Configurations could be replaced by using `artifactView {}` and specifying the attributes?

I'm not sure whether artifact view is not too late to change the attributes.
Maybe the artifact attributes like attribute type, yes.

With IntelliJ 2023.1.1 and Gradle 8.1.1. I get an `java.lang.UnsupportedOperationException` when I try to debug a test. The reason is the code generated by Intellij: ijresolver.gradle: `forkedTask.jvmArgs ("-javaagent:${kotlinxCoroutinesCoreJar?.absolutePath}", "-ea")`. Didn't change a recent release of Gradle setting the jvmArgs?

This depends on how you’re testing. Are testing using Gradle TestKit, or `org.gradle.testfixtures.ProjectBuilder`?

There are two ways of applying plugins. Either by a plugin ID, and the <https://docs.gradle.org/current/userguide/plugins.html#sec:plugins_block|plugins DSL>, (which is what `plugins.register("...")` helps with), or by applying the class directly (<https://docs.gradle.org/current/userguide/plugins.html#sec:old_plugin_application|the ‘legacy’ method>). So, as long as `PluginIWantToTest` is available, you can apply it via the class.

Ah I can do `apply&lt;MyPluginClass&gt;` in the test build script - perfect, thanks!

Have you tried the examples here, with `ResolvedComponentResult`, instead of `ResolvedArtifactResult`?

<https://docs.gradle.org/current/userguide/incremental_build.html#sec:task_input_using_dependency_resolution_results>

No, because I already have working solution with

```variant.runtimeConfiguration.incoming.artifacts.forEach { ... }```
(variant is android stuff)

And since I cannot put variant as task input, i looked for solution and in the doc is this

&gt; In the same vein, if you reference some `ResolvedArtifactResult` instances, you should instead use `ArtifactCollection.getResolvedArtifacts()` that returns a `Provider&lt;Set&lt;ResolvedArtifactResult&gt;&gt;` that can be mapped as an input to your task. The rule of thumb is that tasks must not reference _resolved_ results, but lazy specifications instead, in order to do the dependency resolution at execution time.
I'm currently not sure if it is possible to get  `ResolvedComponentResult` from `variant.runtimeConfiguration`  which is `org.gradle.api.artifacts.Configuration` class.

hmm, it’s possible that not all of the docs are using best-practice for configuration cache

could you try the other example, but use `variant.runtimeConfiguration` instead of `configurations.getByName("runtimeClasspath")`, like this?

```variant.runtimeConfiguration.incoming.artifacts.getResolvedArtifacts();```

I will try.

But it is directly doc about configuration cache
<https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements>)
So I would expected that this will be the source of true :wink:

it would be nice if it was up to date :smile:

It looks that
```@get:Input
abstract val resolvedArtifacts: Property&lt;ResolvedComponentResult&gt;```
with
```variant.runtimeConfiguration.incoming.resolutionResult.rootComponent```
works

At least it no crash. I need to investigate what is inside of ResolvedComponentResult and how to use it.


One thing was not possible to use there.
I was using filter defined like

```variant.runtimeConfiguration.incoming.artifactView {
   attributes {
      attribute(Attribute.of("artifactType", String::class.java), artifactType)
   }
   isLenient = false
}.artifacts.forEach { .... }```


I'm always curious why there are exist to many too similar stuf like `ResolvedComponentResult` and `ResolvedArtifactResult`

me too… <https://github.com/gradle/gradle/issues/23772>

This should help <https://docs.gradle.org/current/userguide/incremental_build.html#sec:task_input_using_dependency_resolution_results>

TL;DR `ResolvedArtifactResult` contains both metadata and files so it cannot be used as a task input directly, you have to extract the data you need from it

I need to get list of all dependnecies, including all transitive dependencies and get group, module, version, artifactType and classifier from all of them.

So far I did not found a way how to do it with
```ResolvedComponentResult```


So group, module and version is OK, but type and classifier still issue :slightly_smiling_face:

artifactType is possible this way :slightly_smiling_face:

```dependency.selected.variants.first().attributes.getAttribute(
    Attribute.of(
        "org.gradle.libraryelements",
        String::class.java
    ))?: "",```


There must be a bug
<https://gradle-community.slack.com/archives/CA745PZHN/p1683322187166639>

Something is for whatever reason trying to read or change or create that `....lck` file in `C:\WINDOWS` which typically is only writable with administrative privileges.

I'd assume that Gradle 7 vs. Gradle 8 is actually a red herring. Try to find out why your build is tring to work with that file at that location and maybe change that in your build.

And check if you have overriden env var or system property for temporary directory since most libs unpack their native bindings to temp dir to load them and somehow that directory was inside read only system directory

thanks for advices, it seems some people also have similar issue on windows
<https://issuetracker.google.com/issues/281439481>

```* What went wrong:
Plugin [id: 'io.micronaut.application', version: '4.0.0-M2'] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (could not resolve plugin artifact 'io.micronaut.application:io.micronaut.application.gradle.plugin:4.0.0-M2')
  Searched in the following repositories:
    Gradle Central Plugin Repository```

```* What went wrong:
Plugin [id: 'com.github.johnrengelman.shadow', version: '8.1.1'] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (could not resolve plugin artifact 'com.github.johnrengelman.shadow:com.github.johnrengelman.shadow.gradle.plugin:8.1.1')
  Searched in the following repositories:
    Gradle Central Plugin Repository```

instead of looking at the trend (which, as you noted, is challenging to determine when something changed), perhaps look at the cache misses and work on optimizing those.

Do you mean build by build? (for example picking those with higher build cache miss from the performance tab). Or any other way to identify this in a more general way?

build-by-build; ultimately you’d end up there anyhow to address issues / optimize hit ratio.

i’ve always set IntelliJ to external changes, which avoids reloading scripts when they are edited in IntelliJ.  I know your pain - ridiculous live-reload stuff that doesn’t know when you are done your changes.

Hm It's funny because I have it set to that setting. Makes me wonder if something confuses it, like the vim plugin...or maybe it isn't refreshing the setting right

ah yea, could be the vim plugin.  haven’t used that myself.  it is the right setting - perhaps the vim stuff is considered “external”.

Hi Martin, nice to meet u again after Kotlin Conf! It looks like some testing frameworks could potentially help u. For example:

• [To create a Project instance](<https://github.com/2BAB/Caliper/blob/main/caliper-gradle-plugin/src/integrationTest/kotlin/me/xx2bab/caliper/gradle/CaliperExtensionTest.kt>)
• [To run Gradle tasks programmatically with `GradleRunner`](<https://github.com/2BAB/Caliper/blob/main/gradle-instrumented-kit/src/main/kotlin/me/xx2bab/gradle/GradleRunnerExecutor.kt>)
• There is an advanced Tooling API [`GradleConnector`](<https://docs.gradle.org/current/javadoc/org/gradle/tooling/GradleConnector.html>) if aforementioned API is insufficient (I haven’t tried yet)

I wouldn't use first or second of these, as they are specifically for unit tests and integration tests respectively. Tooling API I also would have suggested. Not exactly what was asked for, but probably the cleanest way.

Since gradle publish plugin 1.0.0 it is not necessary to add the components manually, right?
```The publications 'java' in project ':hubdle-gradle-plugin' and 'pluginMaven' in project ':hubdle-gradle-plugin' will overwrite each other!```

I would guess it means you have a Java 11 project, but use an annotation processor that can only read Java 8 code or at least declares so. So if you use Java 11 source syntax that this annotation processor does not understand, you could get a bad result.

That’s as expected.  Component capabilities are Gradle-only, not consumed by Maven.  <https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html>

Nor does Maven publish such metadata for consumption by Gradle.

Yeah, I expected Gradle is able to map the &lt;maven.compiler.release&gt; to the Gradle jvm runtime attribute to fail during configuration.

That's not how Maven works though. `maven.compiler.release` is just a property that happens to be used as the default value for `maven-compiler-plugin`'s `release` property. But how about that `release` property being configured explicitly? What if a profile overrides the property with another value? (and remember that this could be inherited from parent POMs) What if command-line overrode the property at the time of publishing? How about some post-processing using some other Maven plugin to make the classes actually compatible with JDK 8? (and I didn't even talk about `maven.compiler.target`)

Honestly, I don’t use maven and don’t know it. So this is also true for maven itself? If I depend on a library compiled with Java 11, maven fetches the lib, but my build fails only during assembling (or even runtime if I use runtime scope)?

You also have to keep in mind, that with Maven the "build recipe" and the "metadata about the published artifact" are mixed up. They are bothin the form of the POM.
Some projects just use the "build recipe" POM also as "metadata abou the published artifact", but then you have to ignore the data that is part of the "build recipe" like the properties you mentioned.

With Gradle Module Metadata this is different.
The Gradle build scripts ar the "build recipe" and the GMM is exactly the published information abou the published artifact.

Fwiw: <https://blog.ltgt.net/maven-is-broken-by-design/#poms-have-two-uses>

Thanks for the answers and the interesting link! With this information I don’t understand why people still use Maven in 2023 :thinking_face: 

FYI, if anyone has an issue with spring-boot &lt;= 2.6.4 not producing executable jar when executing build task after upgrading Gradle &gt;= 8 ; you need to upgrade to spring-boot 2.6.5 at least (I believe this is due to <https://docs.gradle.org/current/userguide/upgrading_version_7.html#abstractarchivetask_api_cleanup|deprecated API being removed>)

hey everyone, i made a circular dependency on accident, and i have no idea how to fix it, please do help. i simply had the file in the wrong package, but after the dependency was done, i don't know how to reverse it, or what it even did to make it depend on eachother

While you actually should not use it at all. :smile:
If you only define it as sole repository, nothing else will be used.

A bit more context:
I have a dependency that I am releasing to `mavenLocal`  repository for testing.  Since this is a test code I am always taking the "currently" released dependency using  dynamic dependency versions. Sometimes this may clash with `mavenCentral` repository resolution.
 (kind of ignore whatever is in in maven central) ?

BTW I would remove `mavenCentral` from my project, but I need other dependencies from there.

You can even do it on a per-dependency basis with "exclusiveContent" or how it was called

Ah, yeah, then the "exclusiveContent" thing is what you want

<https://docs.gradle.org/current/userguide/declaring_repositories.html#declaring_content_exclusively_found_in_one_repository>

try changing

```implementation(files(libs.javaClass.superclass.protectionDomain.codeSource.location))```
to

```api(files(libs.javaClass.superclass.protectionDomain.codeSource.location))```

I presume that `build-logic/kotlin-library/build.gradle.kts` defines a dependency like this?

```implementation(project(":commons"))```

Sadly, tried api instead of implementation, but no luck.

Yes, that dependency is declared indeed

I think you’re just going to have to declare the dependency twice

```implementation(files(libs.javaClass.superclass.protectionDomain.codeSource.location))```


into `kotlin-library/build.gradle.kts` i suppose, already tried that too :grimacing:

No matter what you try, my hack-around will simply not work in that situation for the same reason you also cannot use it within `plugin { ... }` blocks.

The `plugins { ... }` block is extracted and applied to a dummy project to determine which type-safe accessors to generate.

In that dummy project the `LibrariesForLibs` is not present, but it is an essential part of the hack-around that the exact same version catalog is present on the project where you apply it as it on the project where you build the convention plugin.

And exactly that invariant is not given if you apply the one convention plugin inside the `plugins { ... }` block of the other one.

Ok I get it! Crystal clear as always, thanks for the explanation :+1:

The full meaning is hard to tell as you left out half of the error - the part after "but".
But just talking about this displayed Java version, it means that where you consume `convention-plugins` you use Java 11 to run the build (toolchains do not matter here, as it is about a plugin you want to apply, so the version you run Gradle with is the relevant part, toolchains are just what is built).
And if the Java version is, what is complained about, then it means that `convention-plugins` was built with Java 12 or newer and not with a Java 8 toolchain if that is what you meant.

oh. so, plugins are different or don't have a mechanism for toolchains, for their own plugin-developing purposes?

i was hoping to achieve more jdk/toolchain independence, but the plugin level seems to add that hurdle back in, i guess.

For developing a plugin you can of course use toolchains, as I said.
But not for consuming, because you consume them in the Gradle build and thus the Java you run Gradle with is used.

sounds like it could be a network or security configuration issue on your end, as Gradle should be able to fetch <https://plugins.gradle.org/m2/com.gradle/gradle-enterprise-gradle-plugin/3.12.3/gradle-enterprise-gradle-plugin-3.12.3.pom> (works fine for me)

I'm not on a VPN and I've disabled my anti virus

When I clicked on your link it downloaded

Since your link worked and I downloaded : gradle-enterprise-gradle-plugin-3.12.3.pom could I just place the file somewhere to push this forward and get it working

no, there are many other files it needs to fetch as well

if it loads fine in your browser then something is preventing Java from working

Hmmm... I've uninstalled and re-installed Java a few times now... I'm downloading java from here (using Windows 11 OS (64bit) <https://www.oracle.com/java/technologies/downloads/#java11-windows>

More specifically this one: x64 MSI Installer158.74 MB<https://download.oracle.com/java/20/latest/jdk-20_windows-x64_bin.msi> (<https://download.oracle.com/java/20/latest/jdk-20_windows-x64_bin.msi.sha256|sha256>)

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

And once you got a compatible Java, if it still does not sync, try to build from the command line, including the `--scan` option. If it still does not work, try adding `--refresh-dependencies`. Maybe there was a temporary problem to get the file that Gradle still remembers.

It's complaining about the project building your convention plugin, not about the convention plugin itself. So you need to add a toolchain setting to `buildSrc/build.gradle.kts`. but don't use 17 there without reason or you limit the version with which you can execute Gradle to 17+. So unless some dependency requires something higher, use the minimum supported version of your Gradle version there, so most likely 8.

Looks like it goes away in Gradle 7.5, confirmed that for myself. (Gradle 7.4.1 is the version you get when you install Gradle via snap on Ubuntu 22.04.)

Made another attempt today to search for more info about this issue, and I found this: <https://github.com/gradle/gradle/issues/18935>

Ah, right, forgot that issue.
&gt; you get when you install Gradle via snap
I never install Gradle anywhere, as any sane project should contain the wrapper files that should be used to run the build. :slightly_smiling_face:

It was a project I created via `gradle init`, so it installed the wrapper files for 7.4.1. (But those wrapper files are checked in, and they've since been upgraded to 8.0.2; there's a plugin I use that's incompatible with 8.1.1.)