Hi, im developing a gradle plugin compat for kotlin multiplatform project, i want to set the generated/kotlin/commonMain for commonMain sourceSet, set generated/kotlin/nativeMain for nativeMain sourceSet, my code is here

target.extensions.getByType(KotlinMultiplatformExtension::class.java)
                        .sourceSets.findByName(it.value.targetName)?.kotlin
                        ?.srcDir("build/generated/kotlin/${it.value.targetName}")

but it not work, only commonMain sourceSet are be set

hello i needed some help with publishing gradle plugin i am writing gradle plugin for kotlin foundation gsoc i had issues publishing it can anyone help me with it

I have a gradle plugin that needs to find the transitive project dependencies for a project. As of Gradle 8, we do this. However, I was upgrading Gradle and got a deprecation warning we can't access the

dependencyProject

property anymore. What is the Gradle 9 way to do this?

So we distribute our convention plugins via an internal artifactory, but keep them in the same repository for quick iteration, so that when we want to modify them, we just

includeBuild

the directory in our settings script This works fine, however, I want to add all these plugins to the project classpath as such by adding them to the root project build script

plugins {
  alias(libs.plugins.internal.company.plugin) apply false
  alias(libs.plugins.internal.company.otherPlugin) apply false
  // etc
}

When I do this, it works fine until I include the build for local iteration. I basically can’t sync because of the following error

Error resolving plugin [id: 'plugin.name', version: '1.0.43'] > The request for this plugin could not be satisfied because the plugin is already on the classpath with an unknown version, so compatibility cannot be checked.

I’m guessing this happens because when I include the build, gradle seems to add the plugins in it to the classpath with an

unknown

version, but then also tries to grab the latest published versions since I’m also trying to add them to the classpath, thus creating a conflict. Is there any way to work around this or will I have to resort to just commenting out my plugins from the

plugins

block whenever I want to work on them locally?

For Isolated Projects (which we are far, far away from using, but I’m trying to write new plugin code “correctly”) - is the idea that since you can’t access the extensions/properties/other state of other projects, every exchange of information between two project should happen through resolving a

Configuration

with custom attributes a la https://docs.gradle.org/current/userguide/cross_project_publications.html#sec:variant-aware-sharing? Or is there some other way to safely read data from other projects?

Hi there. I am stuck on a gradle build error:

Error resolving plugin [id: 'org.jetbrains.kotlin.multiplatform', version: '2.1.0', apply: false]
> The request for this plugin could not be satisfied because the plugin is already on the classpath with an unknown version, so compatibility cannot be checked.

The error happens in my root build.gradle.kts, probably because of buildSrc dependencies. But buildSrc doesn't use the multiplatform plugin, so this is rather weird. Is there any way to know where the dependency with an unspecified version is coming from?

What does the configurations are initialized lazily of Gradle 8.14 really means for plugin development? I understand that it doesn't really change anything, as things will just continue to work the same; but what if I want to take advantage of that new lazy initialization? Do I understand correctly that it's only a matter of changing:

val myConf = configurations.create("conf")
/* eager configuration */
myConf.… = …
tasks.register<MyTask>("myTask") {
  someProp.from(myConf)
}

to

val myConfProvider = configurations.register("conf") {
  /* lazy configuration */
  … = …
}
tasks.register<MyTask>("myTask") {
  someProp.from(myConfProvider)
}

and

configurations["someConf"].extendsFrom(myConf)

to

configurations.named("someConf") { extendsFrom(myConfProvider.get()) }

?

Question: I currently have, in a plugin:

plugins {
  `version-catalog`
}

catalog {
  versionCatalog {
    version("my-project-version", version.toString())
  }
}

Is it possible to somehow pass in a

Provider

of some kind instead? This is is especially important if I use something like the Reckon plugin, which is causing CC issues because of this eager version resolution.

is there an easy way to gather all the source jars for a

Configuration

? I really hoped something like

def sourceJars = configurations.register('sourceJars') {
    extendsFrom otherConfiguration
    attributes {
        // but with the correct attribute
        attribute LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, 'source-jar'
    }
}

would just get me what I needed, rather than having to go through every jar then request the source jar using

dependencies.createArtifactResolutionQuery()

for each main jar I find?

another question re: Isolated Projects. A common pattern we currently use is: 1. Apply a plugin to the root project, which then: 2. Ensures another plugin is applied every other project We often need this because we want to do something on every Java project, like adding some sort of check or task. We could manually apply the plugins in the buildscript of each project, but this makes it really easy for our devs to forget to add the plugin if they add a new project. It seems this becomes even more necessary to do for Isolated Projects, as you need to make so many variants/configurations in other projects rather than just accessing their state from elsewhere. However, isn’t using the root project to apply plugins other every other project modifying the state of those projects? Isn’t this disallowed? If so, is there some other way to automatically apply a plugin to every project?

if I'm going to write a plugin that is going to be published on the portal and this depends on another module, should this module be published on the portal as well, shouldnt?

I have a multi-module project, one of the module being a custom plugin. This plugin shall be visible to its own module test source code (to be able to apply it on a test project obtained by

org.gradle.testfixtures.ProjectBuilder().build()

), and to other test-only modules. Using the

buildSrc

strategy or the

includeBuild

strategy for the custom plugin module itself are not suitable for this plugin module since it does split the build configuration and make it much harder to mutualize configuration, resources, versions, etc. So I am expecting the custom module plugin to be a standard module among the others, in the same build unit. But the tests modules could be somehow separated, I guess. What are the applicable build architectures for defining, testing and applying a custom plugin that would not isolate the custom plugin module in a separate build context, yet have the custom plugin be visible to tests modules, and to its own tests source code?

Attribute disambiguation I have Gradle plugin in which I create a new component variant

myVariant

with the

runtimeElements

as its base variant and add

myAttribute

with

myAttributeValue

to it. Then I create a configuration where I request

myAttribute

with

myAttributeValue

as the selection preference. However, I'm getting this error.

Caused by: org.gradle.internal.component.resolution.failure.exception.VariantSelectionByAttributesException: The consumer was configured to find attribute 'myAttribute' with value 'myAttributeValue'. However we cannot choose between the following variants of org.acme:lib-a:1.0-SNAPSHOT:
  - myVariant
  - runtimeElements
All of them match the consumer attributes:
  - Variant 'myVariant' capability 'org.acme:lib-a:1.0-SNAPSHOT' declares attribute 'myAttribute' with value 'myAttributeValue':
      - Unmatched attributes:
          - Provides org.gradle.category 'library' but the consumer didn't ask for it
          - Provides org.gradle.dependency.bundling 'external' but the consumer didn't ask for it
          - Provides org.gradle.jvm.version '17' but the consumer didn't ask for it
          - Provides org.gradle.libraryelements 'jar' but the consumer didn't ask for it
          - Provides org.gradle.status 'integration' but the consumer didn't ask for it
          - Provides org.gradle.usage 'java-runtime' but the consumer didn't ask for it
  - Variant 'runtimeElements' capability 'org.acme:lib-a:1.0-SNAPSHOT':
      - Unmatched attributes:
          - Doesn't say anything about myAttribute (required 'myAttributeValue')
          - Provides org.gradle.category 'library' but the consumer didn't ask for it
          - Provides org.gradle.dependency.bundling 'external' but the consumer didn't ask for it
          - Provides org.gradle.jvm.version '17' but the consumer didn't ask for it
          - Provides org.gradle.libraryelements 'jar' but the consumer didn't ask for it
          - Provides org.gradle.status 'integration' but the consumer didn't ask for it
          - Provides org.gradle.usage 'java-runtime' but the consumer didn't ask for it
	at org.gradle.internal.component.resolution.failure.describer.AmbiguousVariantsFailureDescriber.describeFailure(AmbiguousVariantsFailureDescriber.java:56)
	at org.gradle.internal.component.resolution.failure.describer.AmbiguousVariantsFailureDescriber.describeFailure(AmbiguousVariantsFailureDescriber.java:39)
	at org.gradle.internal.component.resolution.failure.ResolutionFailureHandler.lambda$describeFailure$3(ResolutionFailureHandler.java:275)
	at org.gradle.internal.component.resolution.failure.ResolutionFailureHandler.describeFailure(ResolutionFailureHandler.java:275)
	at org.gradle.internal.component.resolution.failure.ResolutionFailureHandler.ambiguousVariantsFailure(ResolutionFailureHandler.java:149)
	at org.gradle.internal.component.model.GraphVariantSelector.selectByAttributeMatchingLenient(GraphVariantSelector.java:155)
	at org.gradle.internal.component.model.GraphVariantSelector.selectByAttributeMatching(GraphVariantSelector.java:82)
	at org.gradle.internal.component.model.LocalComponentDependencyMetadata.selectVariants(LocalComponentDependencyMetadata.java:110)
	at org.gradle.internal.component.model.DelegatingDependencyMetadata.selectVariants(DelegatingDependencyMetadata.java:46)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.EdgeState.calculateTargetNodes(EdgeState.java:257)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.EdgeState.attachToTargetNodes(EdgeState.java:148)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.DependencyGraphBuilder.attachToTargetRevisionsSerially(DependencyGraphBuilder.java:390)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.DependencyGraphBuilder.resolveEdges(DependencyGraphBuilder.java:280)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.DependencyGraphBuilder.traverseGraph(DependencyGraphBuilder.java:205)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.graph.builder.DependencyGraphBuilder.resolve(DependencyGraphBuilder.java:164)
	at org.gradle.api.internal.artifacts.ivyservice.resolveengine.DependencyGraphResolver.resolve(DependencyGraphResolver.java:120)
	at org.gradle.api.internal.artifacts.ivyservice.ResolutionExecutor.doResolve(ResolutionExecutor.java:482)
	at org.gradle.api.internal.artifacts.ivyservice.ResolutionExecutor.resolveGraph(ResolutionExecutor.java:355)
	at org.gradle.api.internal.artifacts.ivyservice.ShortCircuitingResolutionExecutor.resolveGraph(ShortCircuitingResolutionExecutor.java:92)
	at org.gradle.api.internal.artifacts.ivyservice.DefaultConfigurationResolver.resolveGraph(DefaultConfigurationResolver.java:129)

I expected

myVariant

to be the candidate with the "longest" match. I must be missing something. Why is this not the case? Thanks.

Good afternoon Gradle friends! Is anyone able to link to me documentation of how

dependencyResolutionManagement { repositories }

works? Or can someone explain it to me if it isn't documented? I understand that it is currently incubating. As far as I've been able to tell, using it makes the project's own repositories immutable, but that's all I think I understand about it. I do my version catalog management in the

settings.gradle

file, so I'll take any chances to keep as many things related to dependency management in that file as possible.

Hello again. Is it possible, using Nokee's

gradle-plugin-development

plugin, to only use the Gradle API it offers? Here's a screenshot of my dependencies. IntelliJ is still including my Gradle wrapper's API files in the compile classpath. I should mention that I'm also applying

dev.gradleplugins.groovy-gradle-plugin

to the project's plugins.

I have a task that uses a RegularFileProperty as input that should consume 1 file from a resolvable configuration (that only produces 1 file). What’s the best way to support lazy configurations? As a workaround I could use ConfigurableFileCollection as task input but the task only supports 1 file so I would like to keep a RegularFile.

Hey again. I've been playing with

FlowAction

to analyze exceptions thrown by builds to try and report problems using them. I noticed that I can't inject the

Problems

service to them, but I can inject it into

FlowParameters

. It's rather strange but it works. Is there any sort of intentional way to use the problems API within a dataflow action? Or has it just not been implemented yet and is planned?

I am working with a project that has composite builds. I wanted to write my code with regard to the best practices for Isolated Projects. I know this is still in transition and development, but I was wondering if someone had a suggestion. I have Project

base

• IncludeBuild

second

◦ project

a

◦ project

b

:second:a

has a task for executing

verifyPaparazzi

however I can't call it on Project

base

verifyPaparazzi

and subsequently execute Ba's

verifyPaparrazi

it complains that base doesn't have the task. I can call

:second:a:verifyPaparrazi

directly. Which means I can setup a task that is dependent on that task in the

base

project as suggested here My question is, how can I do this dynamically without violating the isolated project best practices. second/settings.gradle.kts

gradle.lifecycle.afterProject {
    if (this.name == "second") {
        return@afterProject
    }

    if (this.rootProject.tasks.findByName("verifyPaparazzi") == null) {
        this.rootProject.tasks.register("verifyPaparazzi")
    }
    val task = this.rootProject.tasks.findByName("verifyPaparazzi")
    this.tasks.findByName("verifyPaparazzi")?.let {
        task!!.dependsOn(it)
    }

}

This then puts a

verifyPaparazzi

call at the

:second:verifyPaparrazi

level instead of

:second:a:verifyPaparrazi

and additional projects that might have it. Collectively putting them into one call at the root of the included build

second

The next step would be to add a task in the

base

project

tasks.register("verifyPaparazzi") {
    dependsOn(gradle.includedBuild("second").task(":verifyPaparazzi"))
}

am I thinking about this all wrong, or is there currently no way to add task dependencies dynamically without violating the Isolated Projects?

Hey everyone! I’m working on a Gradle plugin that registers some tasks using

project.tasks.register

, and it does it inside the

onVariants

lambda provided by AGP. One of these tasks has to search for another task by name, access its outputs, and map them as an input. Something like this:

val targetTaskProvider = project.tasks.named("targetTask") // some task created by another plugin

val myTask = project.tasks.register(...) { task ->
    task.input.set(targetTaskProvider.flatMap { // do some processing on task outputs }
}

When using

project.tasks.named

, if the task I’m looking for has not been registered yet, it will fail to find it. I found that wrapping everything in

project.afterEvaluate

will ensure that the task is already there, but it doesn’t seem optimal. Is there any other alternative?

I want to use artifact transform to transform a dependency's classes and its sources ,but gradle only pass the classes jar to my transformation, so how can i ask gradle to give the sources jar

project.getDependencies().registerTransform(

AccessTransform.class,

parameters -> {

parameters.parameters(p -> {

p.getAccessTransformerFiles().from(extension.getAccessTransformerFiles());

});

parameters.getFrom().attribute(

ModAccessTransformExtension.TRANSFORM_ACCESS,

false

).attribute(ArtifactTypeDefinition.ARTIFACT_TYPE_ATTRIBUTE, ArtifactTypeDefinition.JAR_TYPE);

parameters.getTo().attribute(

ModAccessTransformExtension.TRANSFORM_ACCESS,

true

).attribute(ArtifactTypeDefinition.ARTIFACT_TYPE_ATTRIBUTE, ArtifactTypeDefinition.JAR_TYPE);

}

);

Hello! I'm having difficulties with the Groovy DSL, specifically that I am unable to use the implicit

it

on actions. The script will compile and the

doCall

is intercepted to try and set the property of the current dynamic object. And this is not including types that are `DslObject`s or

DynamicObjectAware

. Both method calls and the short-hand for getters and setters don't work. Basically, this works:

accessTransformers.register {
    it.config = project.file('accesstransformer.cfg')
}

and this doesn't:

accessTransformers.register {
    config = project.file('accesstransformer.cfg')
}

why is that? and is there anything I can realistically do about this without needing to use something like a domain object container? For reference, this is the method they are calling in this example

default AccessTransformersContainer register(Action<? super AccessTransformersContainer.Options> options) {
    return this.register(AccessTransformersExtension.DEFAULT_ATTRIBUTE, options);
}

and this is the exception being thrown:

Caused by: groovy.lang.MissingPropertyException: Could not set unknown property 'config' for project ':at-gradle-demo' of type org.gradle.api.Project.
	at org.gradle.internal.metaobject.AbstractDynamicObject.setMissingProperty(AbstractDynamicObject.java:118)
	at org.gradle.groovy.scripts.BasicScript$ScriptDynamicObject.setMissingProperty(BasicScript.java:170)
	at org.gradle.internal.metaobject.AbstractDynamicObject.setProperty(AbstractDynamicObject.java:76)
	at org.gradle.api.internal.project.DefaultDynamicLookupRoutine.setProperty(DefaultDynamicLookupRoutine.java:42)
	at org.gradle.groovy.scripts.BasicScript.setProperty(BasicScript.java:74)
	at org.gradle.internal.classpath.declarations.GroovyDynamicDispatchInterceptors.callInstrumentedSetProperty(GroovyDynamicDispatchInterceptors.java:102)
	at org.gradle.internal.classpath.declarations.GroovyDynamicDispatchInterceptors.intercept_setProperty(GroovyDynamicDispatchInterceptors.java:89)
	at build_es5ivf5z9jwb4t9pnjernbno6$_run_closure1.doCall$original([path]/at-gradle-demo/build.gradle:9)

If this is a bug, let me know so I can report it. But for now I'm under the assumption that there's a good reason for this.

In a plugin of mine, I'd like to have the same

maven

DSL of the publication task, so in my extension I simply wrote

val maven = objects.newInstance<MavenArtifactRepository>()
fun maven(action: Action<in MavenArtifactRepository>) = action.execute(maven)

but I get: > Could not create an instance of type Library. > > Could not create an instance of type Library$Into. > > Could not create an instance of type org.gradle.api.artifacts.repositories.MavenArtifactRepository. > > Could not generate a decorated class for type MavenArtifactRepository. > > Cannot have abstract method AuthenticationSupported.getAuthentication(): AuthenticationContainer. Is there a way to achieve that?

Hello there. I'm currently working on an Android multi-module project. Among those 42 modules, some are pure Kotlin modules, some are regular android modules and there are also few android modules with flavors. This results in 3 different names for the tasks to execute unit tests: Kotlin modules have just

test

, most android modules have

testDebugUnitTest

and the modules with flavors have also the flavor name inside the task name, like

testStagingDebugUnitTest

. Our goal however is be able to run all existing unit tests in a CI environment using a single command, e.g.

runAllTest

. Additionally, since there are different source sets in some of the flavor android modules, we'd like to have an option to configure what tasks in a given module should be executed to cover all source sets. What would be the recommended way of approaching this topic, that would follow the best practices and work properly with configuration avoidance and configuration cache? In the thread I'm pasting an initial draft of the solution, which definitely can be improved (it uses

afterEvaluate

, which I'm aware is not recommended). There's a convention plugin to register

runAllTest

task, making it dependent on the selected test task name and a custom extension to allow a module define its desired task name.

Hey everyone! Do you know if there’s anything similar to

@SkipWhenEmpty

for a single file? I’d like to configure the input of a task in such a way that the task is skipped if: • The file doesn’t exist. • The input is set with a

provider { null }

. I think this PR asks for something similar, but I couldn’t make it work with a file collection.

Reading task dependencies in Isolated Projects mode I can't seem to get

task.getTaskDependencies().getDependencies(task)

to work when Isolated Projects are enabled. Is there a way or an alternative to that in Isolated Projects mode? Interestingly, while

task.getTaskDependencies().getDependencies(task)

return task dependencies,

task.getDependsOn()

returns an empty set. Thanks!

Is there a good way to access constants defined in the included build, in the outer project buildscripts? I have started moving our multimodule Android project towards convention plugins. Before, all the configuration was done on the root project level via ext properties. So say we had

ext.compileSdk = 23

then subprojects could access it via

rootProject.ext.compileSdk

. Now moved the common plugin configurations to convention plugins in an included build. Say in the included build I have now

object Constants {
  val compileSdk = 23
}

I use this value in the convention plugins, but for legacy reasons this value is also needed in some other buildscript in the project. I don't want to have it duplicated just for that. I think I am able to read that value directly in

*.kts

files but not in

.gradle

files. (Why?) I have figured out I can create some kind of ConstantsConventionPlugin

class ConstantsConventionPlugin : Plugin<Project> {

    override fun apply(project: Project) {
        project.extensions.extraProperties.set("ANDROID_COMPILE_SDK", Constants.compileSdk)
    }
}

Can this be avoided? Is there a better alternative?

Hi everyone, I have a question about using Symlink with a plugin. From my plugin spmForKmp, the user has a folder where he can add/edit swift file. Currently, the plugin copies these files inside a working directory made by the plugin where everything needed is stored. So the Swift compilation error targets the working directory instead of the original Swift directory. I would like to replace the copy by a symlink of the directory, I know it’s technically possible, but is it a good idea?

not sure if it’s been asked before/paged out of search, but somewhere between 8.6/8.9 onwards, it became not possible to automatically download the sources for the gradle api in IntelliJ. I tried it for gradle-api-7.6.4.jar and it appears to download it from “somewhere” into

~/<user.home>/.ideaLibSources

which IntelliJ seems to pick up. This does not happen with later versions of gradle for whatever reason. The workaround I’ve been doing is: • change the wrapper to

-all

distribution and refresh • go to a gradle class and select

Choose sources

• Go to

~/<user.home>/.gradle/wrapper/dists/gradle-<version>-all/<some-hash>/gradle-<version>/src

and select that This obviously doesn’t scale when gradle versions update automatically + many different gradle plugin repositories that I work between. Trying to find an issue on YouTrack and Gradle’s github issue tracker has proven difficult since “gradle” and “intellij” are such common search terms 😅 has anyone actually figured out what the issue is and got it working again? I have a rough feeling that: • https://github.com/gradle/gradle/pull/29320 • https://github.com/gradle/gradle/issues/29483 are somewhat involved, but not sure, hoping someone will know 🙏

Has anyone successfully accessed the test-retry (or develocity) plugin's Test task extension programmatically via a Java or Groovy binary plugin? I'm doing something like:

project.tasks.register('myCustomTestTask', Test {

  TestRetryTaskExtension retry = it.extensions.getByType(TestRetryTaskExtension)
  ...
}

... but this throws o.g.a.UnknownDomainObjectException: Extension of type 'TestRetryTaskExtension' does not exist.

Is it possible to apply

kotlin-dsl

plugin from a regular Project plugin with the default version? I tried this way, it requires adding an explicit dependency

org.gradle.kotlin.kotlin-dsl:org.gradle.kotlin.kotlin-dsl.gradle.plugin

which I want to avoid.

class MyConventionPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        project.pluginManager.apply("org.gradle.kotlin.kotlin-dsl")
    }
}