Hello peeps, I got a request of adding GPG-signature to one of my plugins to support Dependencies Verification. After a bit of research/discussion (and after adding

singing

plugin to the project), we end up concluding the

Plugin Portal

is somehow ignoring

.asc

files, they are not there when requested by URL. Which is not the case for Maven Central's URL. Does anyone knows if this an intentional behavior of Plugins Portal, or a bug?

Hi everyone, I’m centralising common gradle plugins (and config) in team specific gradle plugin. Now I hit problem with merging plugin extensions. So my QualityPlugin applies Detekt and configures detekt to run all rules:

class QualityPlugin : Plugin<Project> {
    override fun apply(target: Project) {
        target.pluginManager.apply(DetektPlugin::class.java)

        target.extensions.configure(DetektExtension::class.java) {
            allRules = true
        }
    }
}

Now I have a project where I want to apply my QualityPlugin and, additionally, set a Detekt base line:

plugins {
 id("my quality plugin name")
}
 
detekt {
    baseline = file("config/detekt-baseline-test.xml")
}

I was expecting Gradle to graciously merge the

allRules

and

baseline

settings in the DetektExtension but alas. The baseline is ignored. What am I doing wrong? Thanks

Could not find method pluginName() for arguments on extension 'intellij' of type org.jetbrains.intellij.IntelliJPluginExtension. Does any one know what is this about? everytime I try to build it pops up

Hi. I'm a developer of a Gradle plugin that uses

TransformAction

. There is a case when

inputArtifact

for

TransformAction

doesn't exist (But it has to be an output artifact of an another subproject). What's the proper way to handle this case? And what are the possible causes of it?

Does anyone know a good way how to find the reason for a

CircularReferenceException

in task ordering besides "just seeing the problem"? I have a cycle and I have no idea where it comes from right now.

Question: when designing a

ValueSource

, is there a serializability requirement on the parameters? eg.

abstract class MyValueSource : ValueSource<String, MyValueSource.Parameters> {
  interface Parameters : ValueSourceParameters {
    val myClient: Property<MyClient>
  }
}

vs.

abstract class MyValueSource : ValueSource<String, MyValueSource.Parameters> {
  interface Parameters : ValueSourceParameters {
    val myService: Property<MyService> // from a BuildService provider
    val clientName: Property<String>
  }
  
  private val myClient = parameters.myService.zip(parameters.myClient) { ... }
}

I seem to recall that there being a case, but I want to make sure, since you can certainly design without.

We have two types of repos, single-project, and multiple-sub-project. We have a conventions plugin that we apply to all projects and sub-projects. It has an extension that accepts the artifact name to be emitted by a given project, and reacts to the presents of the

maven-publish

plugin, configuring publication. e.g.

val artifactName: Property<String> = project.objects.property(String::class.java)

used as

fooConventions {
    artifactName = "my-artifact-name"
}

a few times we’ve run into issues where someone copy-pastes some code and duplicates the artifact name, this unfortunately isn’t caught until the jar file is attempted to be published to artifactory, and user gets an unclear message that the artifact has already been published, and they tend to think it’s a CI problem instead of a project problem. What would be the most ideal way to validate that the configuration across all sub-projects does not contain any duplicates between each project’s

conventions.artifactName

property? Is this a valid use of a Shared Build Service? I could do it simply at the top level project and reach down into the subprojects, but i think then it’d have to be in an

afterEvaluate

which, as i understand it, is detrimental to config caching.

Hey there 👋 I'm developing a Gradle plugin and I want to download a jar (r8 jar) from

<https://storage.googleapis.com/r8-releases/>

. I would normally add an ivy repository from my Gradle plugin to do this but this doesn't work if the consuming project has

dependencyResolutionManagement {
  repositoriesMode.set(RepositoriesMode.PREFER_SETTINGS)
}

I could use a Gradle task to download the jar but then it wouldn't be cached like a dependency download is. Are there other alternatives here?

Hi folks! I'm probably missing something obvious but - is there a simple way (in a Task action) to convert an arbitrary

java.nio.file.Path

into a

FileTreeElement

? The paths are not guaranteed to point to files within the Gradle project; my interest here is in using a

PatternSet

to filter them, but the spec it creates only operates on

FileTreeElement

instances. Is such a thing even possible with the public API?

This message was deleted.

👋 Hello, team! We are getting the below error while running the command on windows, unable to download the plugin, Could you please help here?

hey guys, it's my first time using android studio and i keep on getting this error when i run my code, how can i fix this?

Strange request, is it possible to get a platform’s dependency version? Say there’s a tool that takes a lazy string, how would I go about something like

extension {
    version = configuraitons.oneOfThem.incoming.platforms.matching("spring-boot-dependencies").versionOf("some-sub-dep")
}

That way I lazily retrieve a sub-version of a bom

Hi, @Oleg Nenashev! 👋 Please tell me if there is any officially recommended guideline for naming of plugin IDs. For example, in my case, I want to separate our plugin into two separate ones (for Java and for Scala). So, I’m thinking of naming them 🤔 Was:

com.example.myplugin

Working version so far:

com.example.myplugin-java

com.example.myplugin-scala

But I don’t really like this mixing of separators 🙃

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.