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 address the publication by its name on the _publications_ container.E.g. in Kotlin DSL:
```publishing {
    publications.getByName&lt;MavenPublication&gt;("pluginMaven") { 
       // ...
    }
}```

That said, you can also configure the coordinates the same as in any project: `project.group` and `project.version` in your `build.gradle{,.kts}`, and `rootProject.name` in your `settings.gradle{,.kts}` .

Thanks! That gets me what I needed. My actual case is, I have the plugin name as the `rootProject.name`, but my plugin is in a subproject, but I want to publish it with the `rootProject.name` artifact ID without altering the project name of the subproject. If there is a cleaner way to do that (plugin in subproject, but root project named with plugin name) let me know. :slightly_smiling_face:

It would be cleaner if the subproject name and the artifact ID are the same. Internally, Gradle uses the subproject name as and “identity” and that cannot be changed.

If this is only about the folder name the project is in, you can change the folder of the project `
```include('project-name-that-is-the-artifact-id')
project(':project-name-that-is-the-artifact-id').projectDir = file("the-other-name")```
<https://docs.gradle.org/current/userguide/fine_tuning_project_layout.html#sub:modifying_element_of_the_project_tree>

Could you describe what you were using the filters for?

We're currently using the filters to skip a set of tasks by default where we found it difficult to remove these tasks from the task graph before. Specifically, it's for Spotbugs -- those tasks are slow, and we don't care to run those tasks or their dependencies about 99% of the time.

It's been a long time since I looked at this, but from what I can tell it looks like the task graph `useFilter` options are equivalent to the `-x` option and `ExcludedTaskFilteringBuildConfigurationAction`? I looked into adding a new build configuration action, but it doesn't look like that's well supported. Would the best option be to just add to the `StartParameter#excludedTaskNames` collection?

If you don't want to run those tasks, you can just disable them:
```tasks.withType(SpotBugs).configureEach { spotbugs -&gt; 
   spotbugs.enabled = false 
}```
That could be based on some other state, e.g., you only disable it when you're running a particular task or a particular project property is defined.

Give the property some marker value as convention that signifies not being set and then check whether it is still set to that maker value in your custom validation. This way you could avoid declaring the property as `@Optional`.

No. In order for a plugin to be compatible with both the Groovy and Kotlin DSLs, you need to use Gradle's own extension mechanism. For example, you can imagine the following convention plugin (e.g in `buildSrc/src/main/groovy/my-plugin.gradle`:
```plugins {
   id 'java-library'
}

def ext = repositories.extensions.create("my", MyExtension, repositories)


abstract class MyExtension {
    private final RepositoryHandler repositories
    
    @Inject
    MyExtension(RepositoryHandler repositories) {
        this.repositories = repositories
    }

    void foo() {
    	repositories.maven { it.url = "<https://foo.com>" }
    }
}```
Then you can use it in the Groovy DSL like this:
```plugins {
   id 'my-plugin'
}

repositories {
   my.foo()
}```
and in the Kotlin DSL:
```plugins {
   id("my-plugin")
}

repositories {
   my.foo()
}```
(note, for `RepositoryHandler` this actually only works in 7.4, not before, but in general this is how it should work)
The drawback of this approach is that you cannot _directly_ "extend" the repository handler type: the extension is scoped with a name.

&gt; The drawback of this approach is that you cannot _directly_ "extend" the repository handler type: the extension is scoped with a name.
I was trying to avoid the extension mechanism for that reason but I guess this is the best way until support for custom repository types is added then. Thanks!

Couldn't you have a Kotlin class that overrides the `invoke()` operator for Kotlin, and implements a `call()` method for Groovy? Not entirely sure it'd actually work because of Gradle's special handling of extensions that be used as `my { … }` with a closure/action.

Of course you can do it and without the extra namespacing the extension requires and without the need for 7.4, you just have to provide a Groovy-specific way and a Kotlin specific way that is used by the Groovy-specific way.

Have in some `Foo.kt` (not `kts`, that's important, it must be in a `.kt` even if you otherwise have a precompiled script plugin)
```fun RepositoryHandler.foo() = maven("...")```
this makes it usable from Kotlin DSL scripts.

And then add somewhere in your plugin
```(repositories as ExtensionAware).extra["foo"] = delegateClosureOf&lt;Any&gt; { repositories.foo() }```
which makes it usable from Groovy DSL.

This way you can use it like `repositories { foo() }` from both DSLs.

This isn't a generic solution, though, and it's fairly ugly IMHO

I said it needs special treatment for both DSLs. And I don't disagree that it is somewhat ugly. But from a usage PoV it is nice and convenient and exactly what the OP asked for.

Well, actually I did not fully answer the OP question as it was about overloaded methods for the repository handler.
*But even that works, it just gets even more ugly on the plugin side.* :smile:
In the `.kt` file:
```fun RepositoryHandler.foo() = maven("repo")
fun RepositoryHandler.foo(bar: String) = maven("string/$bar")
fun RepositoryHandler.foo(bar: Any) = maven("any/$bar")```
And in the plugin code:
```(repositories as ExtensionAware).extra["foo"] = object : Closure&lt;Unit&gt;(this, this) {
    fun doCall(vararg args: Any) {
        when (args.size) {
            0 -&gt; repositories.foo()
            1 -&gt; {
                args.first().let {
                    when (it) {
                        is String -&gt; repositories.foo(it)
                        else -&gt; repositories.foo(it)
                    }
                }
            }
            else -&gt; throw NoSuchMethodException()
        }
    }
}```


What I was proposing, fwiw:
```open class MyExtension @Inject constructor(
    private val repositories: RepositoryHandler
) {
    operator fun invoke() = repositories.maven(url = "…")
    operator fun invoke(bar: String) = repoitories.maven(url = "string/$bar")
    // for Groovy:
    fun call() = invoke()
    fun call(bar: String) = invoke(bar)
}
repositories.extensions.create&lt;MyExtension&gt;("my", repositories)```
Still kind of ugly if you ask me, and I'm worried about forward compatibility.

Well, it depends on the Gradle versions you want to support.
Before 7.4 your code will not work, as for `RepositoryHandler` no Kotlin DSL accessors are generated, so you need to provide the extension functions.

And besides that, even with 7.4 `RepositoryHandler` is not formally `ExtensionAware`, so you still need to cast it.

Starting with 7.4 the `invoke` methods for the extensions would work for the Kotlin DSL.
But just having a `call` method still does not work for Groovy.
You need it to be a `Closure` for it to work and then you also have to manually instantiate it.

So for Gradle 7.4 you could do it like
```open class MyExtension : Closure&lt;ArtifactRepository&gt;(this, this) {
    operator fun invoke() = repositories.maven(url = "repo")
    operator fun invoke(bar: String) = repositories.maven(url = "string/$bar")
    operator fun invoke(bar: Any) = repositories.maven(url = "any/$bar")
    fun doCall() = invoke()
    fun doCall(bar: String) = invoke(bar)
    fun doCall(bar: Any) = invoke(bar)
}
(repositories as ExtensionAware).extensions.add&lt;MyExtension&gt;("foo", MyExtension())```
For Gradle &lt;7.4 (also compatible with 7.4+ of course) you need to do it like I suggested, but you can of course do it less ugly then I did originally,
for example like this:
in a `.kt`:
```fun RepositoryHandler.foo() = maven("repo")
fun RepositoryHandler.foo(bar: String) = maven("string/$bar")
fun RepositoryHandler.foo(bar: Any) = maven("any/$bar")```
and in your plugin:
```(repositories as ExtensionAware).extensions.add("foo", object : Closure&lt;ArtifactRepository&gt;(this, this) {
    fun doCall() = repositories.foo()
    fun doCall(bar: String) = repositories.foo(bar)
    fun doCall(bar: Any) = repositories.foo(bar)
})```

But with the latter you then get an unnecessary accessor when used with Kotlin DSL in 7.4+.
So maybe this would be better as it is just for the Groovy part:
```(repositories as ExtensionAware).extra["foo"] = object : Closure&lt;Unit&gt;(this, this) {
    fun doCall() = repositories.foo()
    fun doCall(bar: String) = repositories.foo(bar)
    fun doCall(bar: Any) = repositories.foo(bar)
}```

How are you supposed to wire dependencies if you no longer expose `Provider`s? e.g. `tasks.someTask { someProperty.set(someExtension.value) }`: if `value` is a `Provider` then it can be (re)configured *after* the wiring, otherwise you're forced to write `someProperty.set(provider { someExtension.value })`. And in case `value` is actually computed by another task, you also get an implicit dependency on that task that you lose with `provider {}`.
…for the very small gain of writing `value = "foo"` rather than `value.set("foo")`.

The focus here is concise end-use api and easy fallback property chaining. For library authors the syntax is more verbose to achieve that, but in a nutshell, you'd never use delegated access internally when applying your plugin logic and instead would use actual properties with internal visibility. So you'd have something like `tasks.someTask { someProperty.set(someExtension._value) }`  where _value is of type Property with internal visibility

Obviously this does not work if your consumer wants to make use of this for local custom tasks. It's not a silver bullet that fits all kind of plugins.

I like the project, and I understand where you are coming from with this. But, I'm with <@UDC9Q9RD0> here and also believe that Gradle should not add this API. It's just another way to do the same thing with reduced functionality and additional reflection overhead. However, nothing wrong with a little project that can be used by those who cannot stand the `.set(...)` instead of `= ...`.

<@U01A244DYUF> where does reflection come in all this? I thought delegates are just syntactic sugar handled by the compiler?

Just look at the signature of any standard `getValue` function and you have your answer.
```operator fun getValue(thisRef: Any, property: KProperty&lt;*&gt;)```
Notice the `KProperty&lt;*&gt;` which originates from, well, reflection.

I kinda assumed it to be shallow reflection like MyType::class

`KPropery&lt;*&gt;` is one of the reflection primitives found in the stdlib and not the reflection.

That being said, the `getValue` operator function does not rely on reflection at all

Aha! I knew I didn't dream it up :grinning:

<https://kotlinlang.org/docs/delegated-properties.html#translation-rules-for-delegated-properties|https://kotlinlang.org/docs/delegated-properties.html#translation-rules-for-delegated-properties> it's even stated in the docs with illustration of the generated code. Also directly go to the next heading after the one I linked, this was added recently and doesn't need reflection. 

Reflection primitive or full reflection almost never matters, it's still Java reflection underneath.

&gt; and `this::prop` is a reflection object of the `KProperty` type describing prop itself.

Following your logic, does that mean passing method references instead of lambdas as arguments also use reflection??

```public void sayHi(Predicate&lt;String&gt; filter) {}
public Boolean myPredicate(String value) {}
public static void main() {
  sayHi(::myPredicate)
  // VS
  sayHi((value) -&gt; true)
}```

I'd expect the Kotlin compiler to do the same kind of code generation as the Java compiler on that one, and *not* use reflection. That said, KProperty implementations _could_ probably also be generated at compile-time and not use reflection, I have no idea what the Kotlin compiler actually does (maybe have a look at your `build/classes/…` dir and possibly use `javap` to find out)

Function references are different, they are not going to be handed over to another function that expects a `KFunction` (or anything like that). What it generates also depends on what `kotlinc` flags you have used. By default it generates a `kotlin.jvm.functions.FunctionXXX` (where `XXX` is the artity, so e.g. `0` for no args, `1` for one arg, up to `22`). However, you can pass `-Xlambdas=indy` (JVM 8+) to use `invocedynamic` instead. (There are also `-Xsam-conversions=indy` and `-Xstring-concat=indy` [JVM 9+].) This is the reason why it's important to use `inline` whenever you take a lambda. If you do that the `FunctionXXX` does not need to be created. However, something many people are often not looking out for is the the code that is going to be inlined should be minimal, or it disables the optimization functionalities of HotSpot.

Given:
```package com.hellofresh

import java.util.function.Predicate

class C {
    fun sayHi(filter: Predicate&lt;String&gt;) = Unit
    fun myPredicate(value: String): Boolean = true
}

fun main() {
    val c = C()
    c.sayHi(c::myPredicate)
}```
The Kotlin Bytecode viewer of IntelliJ gives:
```// C.java
package com.hellofresh;

import java.util.function.Predicate;
import kotlin.Metadata;
import kotlin.jvm.internal.Intrinsics;
import org.jetbrains.annotations.NotNull;

@Metadata(
   mv = {1, 5, 1},
   k = 1,
   d1 = {"\u0000$\n\u0002\u0018\u0002\n\u0002\u0010\u0000\n\u0002\b\u0002\n\u0002\u0010\u000b\n\u0000\n\u0002\u0010\u000e\n\u0000\n\u0002\u0010\u0002\n\u0000\n\u0002\u0018\u0002\n\u0000\u0018\u00002\u00020\u0001B\u0005¢\u0006\u0002\u0010\u0002J\u000e\u0010\u0003\u001a\u00020\u00042\u0006\u0010\u0005\u001a\u00020\u0006J\u0014\u0010\u0007\u001a\u00020\b2\f\u0010\t\u001a\b\u0012\u0004\u0012\u00020\u00060\n¨\u0006\u000b"},
   d2 = {"Lcom/hellofresh/C;", "", "()V", "myPredicate", "", "value", "", "sayHi", "", "filter", "Ljava/util/function/Predicate;", "kotlin-libs.logging.main"}
)
public final class C {
   public final void sayHi(@NotNull Predicate filter) {
      Intrinsics.checkNotNullParameter(filter, "filter");
   }

   public final boolean myPredicate(@NotNull String value) {
      Intrinsics.checkNotNullParameter(value, "value");
      return true;
   }
}
// TestKt.java
package com.hellofresh;

import java.util.function.Predicate;
import kotlin.Metadata;
import kotlin.jvm.functions.Function1;
import kotlin.jvm.internal.Intrinsics;
import org.jetbrains.annotations.NotNull;

@Metadata(
   mv = {1, 5, 1},
   k = 2,
   d1 = {"\u0000\b\n\u0000\n\u0002\u0010\u0002\n\u0000\u001a\u0006\u0010\u0000\u001a\u00020\u0001¨\u0006\u0002"},
   d2 = {"main", "", "kotlin-libs.logging.main"}
)
public final class TestKt {
   public static final void main() {
      C c = new C();
      Function1 var1 = (Function1)(new Function1(c) {
         // $FF: synthetic method
         // $FF: bridge method
         public Object invoke(Object var1) {
            return this.invoke((String)var1);
         }

         public final boolean invoke(@NotNull String p1) {
            Intrinsics.checkNotNullParameter(p1, "p1");
            return ((C)this.receiver).myPredicate(p1);
         }
      });
      c.sayHi((Predicate)(new Predicate(var1) {
         // $FF: synthetic field
         private final Function1 function;

         {
            this.function = var1;
         }

         // $FF: synthetic method
         public final boolean test(Object t) {
            Object var10000 = this.function.invoke(t);
            Intrinsics.checkNotNullExpressionValue(var10000, "invoke(...)");
            return (Boolean)var10000;
         }
      }));
   }

   // $FF: synthetic method
   public static void main(String[] var0) {
      main();
   }
}```
As you can see, here it even creates two objects under the hood.

I specifically gave my example in java to understand how java handles such cases

I know kotlin has lots of tricks up its sleeve to help avoid lambdas, but I used lambas as an example for java day-to-day reflection in the first place :smile:

Java introduced lambdas with 8 and uses said `invokedynamic`. Kotlin does not because Kotlin has back comp down to 6.

<https://www.baeldung.com/java-invoke-dynamic>

You cannot set the version of the plugin in your test build.gradle, you need to add it to the classpath

If you want to use other versions...

You can create another configuration and do .. 

// Inspired by: <https://github.com/square/sqldelight/blob/83145b28cbdd949e98e87819299638074bd21147/sqldelight-gradle-plugin/build.gradle#L18|https://github.com/square/sqldelight/blob/83145b28cbdd949e98e87819299638074bd21147/sqldelight-gradle-plugin/build.gradle#L18>
// Append any extra dependencies to the test fixtures via a custom configuration classpath. This
// allows us to apply additional plugins in a fixture while still leveraging dependency resolution
// and de-duplication semantics.
tasks.named("pluginUnderTestMetadata", PluginUnderTestMetadata::class.java) {
  pluginClasspath.from(fixtureClasspath)
}

And if you want to use second approach, better use a dedicated directory instead of `mavenLocal()` or at least use a repository content filter so that only your plugin is taken from there.

I want use WithPluginClasspath way! But it fail, because gradle do not resolve all dependency for kotlin plugin, and i have ClassNotFoundException

I was expecting the WithPluginClasspath way to resolve the same kotlin dependencies as publicToLocalMaven. But that's not true.
Same project with publicToLocalMaven way build successfully, but with WithPluginClasspath way faild with ClassNotFoundException

if these methods lead to different sets of dependencies, then should i prefer publicToLocalMaven because it's more reliable?

*Cristian,* i read you note, and try to analyze you repository, but it is so hard for me. As I understand it, you were talking about extra dependencies, but I have a problem with core gradle dependencies(kotlin-gradle-plugin-api missing)

Thx for the information, then it should not take long

I don't think so.
The Gradle logging system is extremly unconfigurable afaik.
You can just set own logging implementation and handle the log events yourself to handle them like you want.

cheater! you didn't complain so much while you worked there!

BTW I had similar errors recently, but I saw what happened in the stacktrace I think

The provider errors are the worst especially when they happen during task input snapshot. It’s even worst when you have a cycle hidden in the provider value generation, e.g. deriving a value from other values without mapping.

```class SeatGeekPlugin : Plugin&lt;Project&gt; {

    override fun apply(target: Project) = with(target) {
        val arch2 = extensions.create("arch2", Arch2PluginExtension::class.java)

        afterEvaluate {
            if (arch2.isConfigured) {
                val moduleSetup = archetypeConfigToModuleSetup(target, arch2.archetypeConfig)

                moduleSetup.plugins.forEach { plugin -&gt;
                    println("Plugin: $plugin")

                    when (plugin) {
                        is Plugin.Class -&gt; project.plugins.apply(plugin.clazz)
                        is Plugin.Id -&gt; project.plugins.apply(plugin.id)
                    }
                }

                moduleSetup.dependencies.forEach { dep -&gt;
                    when (dep) {
                        is Dependency.Maven -&gt; target.dependencies.add(dep.configuration.asGradleConfigurationString(), dep.coordinates)
                        is Dependency.Module -&gt; target.dependencies.module("${dep.configuration.asGradleConfigurationString()} ${dep.path}")
                    }
                }
            }
        }
    }
...
}```


The plugin *is* applied in time.
Indeed immediately.
Even though you use the legacy way of applying it instead of the `plugins` block.
But you explicitly delay most of the work to later, after the build script was evalutated using `afterEvaluate` which is almost never a good idea to use.

hmm, it seemed that if I didn't include it in afterEvaluate {} then the arch2 extension wasn't yet parsed from the build.gradle

So with this feedback I tried something different -- injecting project into the extension and then applying the necessary plugins from the view{} block and that seems to work. Is that the "right" way?

Of course the extension is not yet configured without `afterEvalutate`, as the `apply` is of course before the extension.
When the plugin is applied it adds the extension, so it cannot be configured before the plugin is applied.
I'm not sure how you mean it exactly, but I guess yes, having a method in `view` instead of a property and reacting to the method call.

It's working! Configuring the project from within the Extension implementation :party-gradlephant:

Can you elaborate what you mean?
You apply a plugin to the root project.
The plugin adds an extension to the root project.
And now you want what?

In submodules, I want to then be able to specify

```arch2 {
    view {
    ...
    }
}```
and in my Arch2Extension, inject `Project`  as I do now, but have it represent the submodule instead of the root project where the plugin was initially applied.

So right now in the Arch2Extension I have

```abstract class Arch2PluginExtension @Inject constructor(
    private val target: Project,
) {
...
}```

but this Project is the root of the project instead of the submodule where `arch2` is found

Ah, maybe I'm meant to change the plugin to target.subprojects.forEach { it.extensions.create(...) }

Log under TestKit looks like this:
```# first run:
Configuration cache is an incubating feature.
Calculating task graph as no configuration cache is available for tasks: approveRelease
Inferred project: test, version: 0.2.0-dev.1+3ffa845

Release 0.2.0-dev.1+3ffa845 version? [yes, no] 

&gt; Task :approveRelease
answer: true

BUILD SUCCESSFUL in 177ms
1 actionable task: 1 executed
Configuration cache entry stored.

# second run:
Configuration cache is an incubating feature.
Reusing configuration cache.

Release 0.2.0-dev.1+3ffa845 version? [yes, no] 

&gt; Task :approveRelease FAILED
answer: null```

Real world run:
```# ➜ gradle approveRelease --configuration-cache
executing gradlew instead of gradle
Configuration cache is an incubating feature.
Calculating task graph as configuration cache cannot be reused because an input to task ':private-repo:compileKotlin' has changed.
&gt; Task :build-logic:generateExternalPluginSpecBuilders UP-TO-DATE
&gt; Task :build-logic:extractPrecompiledScriptPluginPlugins UP-TO-DATE
&gt; Task :build-logic:compilePluginsBlocks UP-TO-DATE
&gt; Task :build-logic:generatePrecompiledScriptPluginAccessors UP-TO-DATE
&gt; Task :build-logic:generateScriptPluginAdapters UP-TO-DATE
&gt; Task :build-logic:compileKotlin UP-TO-DATE
&gt; Task :build-logic:compileJava NO-SOURCE
&gt; Task :build-logic:pluginDescriptors UP-TO-DATE
&gt; Task :build-logic:processResources UP-TO-DATE
&gt; Task :build-logic:classes UP-TO-DATE
&gt; Task :build-logic:inspectClassesForKotlinIC UP-TO-DATE
&gt; Task :build-logic:jar UP-TO-DATE
locking FileBasedConfig[/home/gross/.config/jgit/config] failed after 5 retries

&gt; Configure project :private-repo
Inferred project: private-repo, version: 0.14.0-dev.2.uncommitted+8fda41b

&gt; Task :private-repo:compileKotlin UP-TO-DATE
&gt; Task :private-repo:compileJava NO-SOURCE
&gt; Task :private-repo:pluginDescriptors UP-TO-DATE
&gt; Task :private-repo:processResources UP-TO-DATE
&gt; Task :private-repo:classes UP-TO-DATE
&gt; Task :private-repo:inspectClassesForKotlinIC
&gt; Task :private-repo:jar
locking FileBasedConfig[/home/gross/.config/jgit/config] failed after 5 retries

Release 0.1.0-dev.0.uncommitted version? [yes, no] yes


&gt; Task :approveRelease
answer: true

0 problems were found storing the configuration cache.

See the complete report at file:///home/gross/repo/dev-infra/[redacted]/build/reports/configuration-cache/9f4g5irc79mlsbjt5bhvn1n3y/acr0wm9gt2pmg5vvajfbmyfbr/configuration-cache-report.html

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See <https://docs.gradle.org/7.4/userguide/command_line_interface.html#sec:command_line_warnings>

BUILD SUCCESSFUL in 12s
16 actionable tasks: 3 executed, 13 up-to-date
Configuration cache entry stored.
# at [03:15:05] ➜ gradle approveRelease --configuration-cache
executing gradlew instead of gradle
Configuration cache is an incubating feature.
Reusing configuration cache.

Release 0.1.0-dev.0.uncommitted version? [yes, no] yes


&gt; Task :approveRelease
answer: true

BUILD SUCCESSFUL in 2s
1 actionable task: 1 executed
Configuration cache entry reused.```

Versions are irrelevant, since they use different repos, task itself is quite trivial which is why I decided to try test infra on it:
```abstract class ReleaseApproveTask : DefaultTask() {
  @get:Input
  abstract val projectVersion: Property&lt;String&gt;

  @get:Input
  abstract val approve: Property&lt;String&gt;

  @TaskAction
  fun run() {
    if (approve.get() == "true") {
      return
    } else if (approve.get() == "false") {
      throw GradleException("Not approved, use -Prelease.approve=true for non-interactive mode to approve release")
    }

    val userInputHandler = services.get(UserInputHandler::class.java)
    val answer = userInputHandler.askYesNoQuestion("Release ${projectVersion.get()} version?")
    logger.lifecycle("answer: $answer") // tmp
    if (answer == null || !answer) {
      throw GradleException("Not approved, use -Prelease.approve=true for non-interactive mode to approve release")
    }
  }
}```

With TestKit you probably get the non-interactive implementation: <https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gradle/api/internal/tasks/userinput/NonInteractiveUserInputHandler.java|https://github.com/gradle/gradle/blob/master/subprojects/core/src/main/java/org/gr[…]pi/internal/tasks/userinput/NonInteractiveUserInputHandler.java>

It doesn't seem so, non-interactive would return `null` in both calls but first call gets `true`. I only see such behaviour when configuration cache is reused.

After reviewing my code I found that I forgot to reset input stream that provides that answer on second run. And since it was added only for testing configuration cache it was suspect.

Besides that it is not the same code (`libraryAliases` vs. `dependencyAliases`), you just call it on the wrong object.

You look in the `extensions` of the `Task` which also is `ExtensionAware` but does not have the extension you are after and if you query `extensions` explicitly there is no delegation strategy.

Use `project.extensions` and it should work just fine.

Maybe someone should post a feature request to add the `ExtensionAware` instance to the error message, I also fell into that trap a few times already.

You should look at what I'm doing here: <https://github.com/micronaut-projects/micronaut-build/tree/master/src/main/java/io/micronaut/build/catalogs>

I don't think using the API you mention is going to help you because it represents a _realized_ catalog. Typically won't give you where a version is defined.

&gt; I don't think using the API you mention is going to help you because it represents a _realized_ catalog. 
That's fine, I'm not modifying the file `libs.versions.toml`,
I'm using its content to rewrite the files `build.gradle(.kts)` 
 <https://github.com/jmfayard/gradle-versions-catalog/commit/c9f9dfe12861ea409c06416fc2d25f150067e9fb>

mmm, having the versions in a separate file kind of defeats the concept, no?

Generating the `libs.versions.toml` and updating the `build.gradle(.kts)` is half of the work of integrating refreshVersions and the versions catalog.

The second half will be that refreshVersions add the available versions updates as comments in the `libs.versions.toml`  directly, if the versions are present there.

we found a "funny" bug in our Micronaut build plugins, because they were using `reports._register_`, which is lazy.

So basically, no reports were _ever_ created, because no one was ever eagerly creating them

so the jacoco aggregate report task was never created...

it's arguable if our plugin should use `create` instead of register (it probably should), but from the plugin point of view, I think semantically, what you want is really: for each report in the _model_, _register_ a task. So the model must be _eager_, but the _tasks_ must be lazy.

This is a known situation, where we have lazy methods available on containers which aren’t lazy. Like the publication model, for example.

Let’s talk more about how this didn’t work as expected for Micronaut.

this is the commit which fixed it: <https://github.com/micronaut-projects/micronaut-build/pull/274/commits/fbfe61ef2270fb6118881726ae3b39cc8de1b28e> (note this is a PR, the bug was in a PR)

I’d argue that plugins, core and otherwise, should use `register` and there should be a consumer at a definite point in time.

Making everything eager now (core and plugins) goes against the configuration avoidance discipline we’ve been working to establish.

According issue for reference: <https://github.com/gradle/gradle/issues/19955>

Thanks for posting the link to the issue, Björn. This should be coming in 7.4.1.

In the meantime, Rodrigo let’s talk about how to make non-lazy containers… lazy. :slightly_smiling_face:

yeah I'm a bit puzzled about what is supposed to trigger the consumption :slightly_smiling_face:

The core problem (I can talk at length with experience with Nokee and the whole native ecosystem in Gradle, software model included) is discoverability. Everything is fine regarding laziness, but Gradle doesn’t know which container _produce_ which domain objects. You can go even further to say which _elements produce_ other domain objects. Saying that some domain container are eager while others aren’t is extremely confusing but also goes around the core issue because some situation may create a cascading effect which blow up the configuration time. Feel free to reach out, Sterling and I had a lot of discussion around similar issues.

Hi Daniel. Yes, Sterling and I were just talking about you and the native ecosystem w.r.t. both this and adding more flexibility to dependency resolution. We’ll be in touch.

While fat jars imho are generally a very bad practice, in this case of that private dependency it might be appropriate. You can probably use the `shadow` plugin of John Engelman to build your fat jar and configure it to be published instead. But you also have to make sure the dependency does not land in the metadata files, maybe by declaring it as `compileOnly` or similar.

Also if it’s a private dependency, you may want to minify/obfuscate it using e.g. Proguard

Thanks for the hints, guys, much appreciated!
I will investigate `shadow`, don’t need `Proguard` at the moment, but good to know it exists.

Even if it were possible (not sure whether it is), I doubt that it is a good idea.
May I ask what you actually want to achieve that you try to solve with that detection?

Well I was thinking of making myself a gradle plugin that would manage my git hooks. I could just write them each project sync, but I was hoping to avoid some IO and only write them when a project is being synced in IDE. I could also check an existence of idea.sync system property, but that would only work with intellij.

You could make it a manual step.
Or / and given there are tests run, you could have one that verifies the hooks are up to date and fail otherwise.
I'm not sure whether you could detect tooling api use, but even if I'm not sure that would help.
While I'm not sure whether the commandline client uses a different way or basically also the same interface,
you would then get all invocations through IDE, not only syncs.

Hey Chris,

Can you check with different 7.x versions? Trying to assess where this changed.
Also, please open an issue and if you can add a reproducer, that would help a lot in tracking this down.

Thanks for reaching out Louis. We figured out what went wrong on our side. A crucial call was missed when porting to the new API and that caused the classpath to not include our additional jars.
```Directory libsDir = ...
classLoaderWorkerSpec.getClasspath().from(libsDir)```
needed to be
```Directory libsDir = ...
classLoaderWorkerSpec.getClasspath().from(libsDir.getAsFileTree())```
Sorry for the false alarm.

Aren't that 2 different questions?

• How to wire artifact from one project to another
• How to use a transform as a task input

For the first, I guess it's:
<https://docs.gradle.org/current/userguide/cross_project_publications.html|https://docs.gradle.org/current/userguide/cross_project_publications.html>

no, my question is more about how to configure the task using output of another task. But, I think, it is not possible in the Gradle paradigm as execution happens after configuration phase

configure, not use the output as an input?

if so, yes, you cannot read a task output to configure another task, but it seems weird

I suppose all this is used in some task action?

probably your task could use more specific types of inputs?

Ok, but how?
I need to know when my task action is run,
which dependencies are applied to the build,
and which are present in `gradle/libs.versions.toml`

Have you tried to use `SetProperty&lt;Dependency&gt;` type as task input type for dependencies? And for version catalog `Provider&lt;Iterable&lt;VersionCatalog&gt;&gt;` ?

Gradle won't create a provider of VersionsCatalog, probably not serializable

For the dependencies, I think I need the upcoming feature in 7.5 to depends on the dependency graph in a lazy manner

<https://github.com/gradle/gradle/issues/12871#issuecomment-1009758750>

Probably for now you could mark your plugin tasks as non-configuration-cache compatible: <https://docs.gradle.org/7.4/userguide/configuration_cache.html#config_cache:task_opt_out>

Iirc just an internal helper you can use for it but not an officially sanctionated API

I think what I have in mind is `zipTo` in the `kotlin-dsl`

dang, not so easy... more specifically I want to be able to create either a zip, or tarball

Make a `Zip` task and a `Tar` task and create both if the user chooses so. :slightly_smiling_face:

I can't... because I need the zip to be created in a build service

this is for tests, I want to check that my plugin works with different file formats. I have a flat dir, but I need to check it will also work with zips or tarballs as inputs.

now the easiest just seems to create the archives beforehand. But whatever I do, I need to create an archive

actually I went in 2 phases. I created tasks for each format, then I run my test in 2 phases. The first one simply creates the task, so that the 2d run, which uses tasks which consume the build service, have the zip at hand. It Just Works :tm:

Is there a reason not to use the regular syntax of:
```@get:Input
abstract val myProperty: Property&lt;String&gt;```
I've also seen people use an `open` class and initialize the non-abstract property from the objects factory, that way you don't need the `@get:` target

either `abstract fun getMyProperty()` or `abstract val myProperty`

I prefer
```@get:Input
abstract val myProperty: Property&lt;String&gt;```
as a rule

You can pass providers to the `FileCollection` factory methods or `from()`, so: `project.files(myProvider)`

I guess it should be documented somewhere, it took me a while to figure it out when I needed it.

One issue I am still hitting that `Provider&lt;*&gt;` is queried on configuration phase and not on execution:
```@get:Input
val scriptExtensions: SetProperty&lt;String&gt; = ...

@get:InputFiles
@get:SkipWhenEmpty
@get:IgnoreEmptyDirectories
@get:PathSensitive(PathSensitivity.RELATIVE)
internal open val scriptSources: FileCollection = objectFactory.fileCollection().from(scriptExtensions.map { if(it.isEmpty()) emptySet() else scriptFiles.matching { ... } })```

wrapping into `from({ scriptExtensions.map { ... } })` doesn't help as well

I know tasks are configured in the configuration phase and not in the execution phase. Actually, I could put info in some files, and uses thoses files as task input

Actually such "configuration tasks" that configure another task in their execution phase are simply possible.

But they are bad practice and no longer possible if you care about the upcoming configuration cache which makes them illegal of course.

Right, but using a file would work and be less a bad practice right? I don’t know much about the Provider API, but is it possible to output a provider from a task and consume it in another task ?

Writing to a file is probably the cleanest solution, yes.
Especially as only file outputs can properly be considered for up-to-date checks.

I found evaluate() :smile:

`(project as DefaultProject).evaluate()`

 but that doesn’t make the Listener get called :thinking_face:

I got rid of the `DependencyResolutionListener` and used `project.dependencies.add()`  directly in my plugins apply method :shrug:

I believe something similar has been discussed a few weeks ago. The outcome of the discussion was, IIRC, to use methods in your extension rather than properties, to make it clear that it's "imperative" (think about `useJUnit()`/`useTestNG()` of the `Test` task, not identical but it makes it clearer that it will reset/clear some configuration and not just change a property value)

Actually `afterEvaluate` would not be too late to add dependencies or apply plugins. But everytime you use `afterEvaluate` you create new race conditions as you then depend on ordering and for example don't see changes done in `afterEvaluate` blocks done after your `afterEvaluate` block.

And as Thomas correctly said, imho using a method in the extension is the best way, as there is not way to react to properties being set currently. You can either have a method like `useSetupX()` or also with parameters that then does what you need, or you can have something like a `doThings(Action&lt;SubExtension&gt;)` so that you then can have
```myExtension {
    doThings {
        subExtensionsPropertyA.set(1)
        subExtensionsPropertyB.set(1)
    }
}```
and then in the `doThings` before executing the action you could check it was not already configured and after executing the action you can derive your logic from it.
Whichever way you prefer.

Thank you for the help. So if I wanted to have some default configuration, do you think that would also make sense to be a method? Or I suppose if I call a method I could potentially remove a dependency. And I definitely agree that I would prefer to avoid afterEvaluate as much as possible.

To give a more concrete example, I was mostly thinking that maybe the default would be useJUnit() for example, but if the user called useTestNG() I would have to remove the junit deps and then add the test ng deps, right?

I'm not sure whether removing dependencies works or is a good idea.
Maybe in that case you need something like `beforeResolve` where you add the default dependencies if nothing was configured in the extension.
Or maybe even better you create a new (possibly hidden) configuration where you define default dependencies to be the default ones and if the method is called add non-default dependencies, this way the defaults are only used if no were set explicitly.

Ahh I didn’t know about `beforeResolve`. I suppose that happens post configuration but before tasks are evaluated.

It happens before the respective configuration is resolved. That can be before some tasks are executed but after others are executed because not all tasks need the configurations.

Have you considered using different/multiple convention plugins instead of an extension?

For example:
*Option 1*: Give several alternatives (one for each combination of things that makes sense in your project)
```plugins {
  id("my-java-project-with-junit")
}```
Or
```plugins {
  id("my-java-project-with-testng")
}```
*Option 2:* Let the users “stack” convention plugins
```plugins {
  id("my-java-project") // JUnit is the default here
}```
Or
```plugins {
  id("my-java-project")
  id("my-extra-testng") // Switches to things TestNG
}```
I recently strictly use Option 1 several projects which gives you all the control in the plugins and makes it easy to use/understand for the developers as you have a limited set of predefined combinations. If the number of combinations explodes, Option 2 might be better though.

If you feel that you need extensions, I would also do what was proposed above - offer methods on the extensions - like your own `myExtension.useTestNG()` which then directly modifies the declared dependencies (and whatever else you want to configure).

Thanks for commenting. I didn’t consider stacking convention plugins like that. If I used option 2, how would I know to apply the junit dependencies for example? I suppose I would be monitoring the plugins as they are added and if I see the TestNG plugin show up I would remove a beforeResolve listener on the configuration I’d be using to add the junit dependencies? Or is there an even easier way Im missing

The one I said but you ignored?
Make a new configuration, add junit as default dependencies, when testng is applied add testng as actual dependencies and make `testImplementation` or whatever you would have added them otherwise extend your new configuration.

I think there are several options. Using an additional configuration is an option or modifying the dependencies of `testImplementation` directly is another one.

I think in this case I would probably add the junit dependency directly to `testImplementation` in the `my-java-project`.
And then in the the `my-extra-testng` I would replace/remove the junit dependency again. I would also make `my-extra-testng`  apply `my-java-project` in its plugins block so the order is always clear.

<@URQ797WRW> Sorry if I offended you. I didn’t mean to ignore any suggestions you have made. The question was more towards <@U023HSZL88M> but I think we are thinking on the same wave length. Thank you all again for your help and insight on this.

No offense happened, don't worry :slightly_smiling_face:

<https://melix.github.io/blog/2022/03/gradle-conditional-dependencies.html> this actually seems relevant to my discussion for any future readers that come across this thread.

Good read. You have great fixtures, some aligns with my view for a better testing with Gradle. I still believe the Gradle team should offer more test framework agnostic APIs to help testing.

curious what kinds of APIs you have in mind?

:wave: nice writeup

I started with similar approach of auto generating the build files from unit tests but as complexity started to get unwieldy I shifted towards defining integration test projects explicitly that are invoked from unit tests using  `GradleRunner`

that being said -&gt; as the number of integration tests grow... `GradleRunner` is pretty slow... wondering if folks have some suggestions on how to speed things up

right now I'm thinking about using JUnit tags to group stuff together and run "basic" integration test in main build and whatever other groups in parallel afterwards (using actions)

it is much slower than unit tests by definition. I didn't include it in my post, but in the repo I have a larger build.gradle that includes parallel test execution

in the OSS plugin I maintain, I have a basic separation of tests by package, so folks can run a subset. It's very coarse-grained, just two, but it's been useful at times. (android vs jvm packages means java devs don't have to run the android tests)

&gt; wondering if folks have some suggestions on how to speed things up
Run tests in parallel, use minimum external dependencies in test projects.

funnily enough, one of my methods for keeping things fast is to write JVM fixtures whenever possible. Android fixtures are much slower

<@UACGKT8S1> already doing that, it takes forever for GradleRunner to spin up a new instance (guessing it is starting a demon)

interesting, I see daemon for each test is reused :thinking_face:

it looks like they are reused from within the same class but not across

I think you are right, but you could run different test classes in parallel

it is still pretty slow -&gt; hence the plan of moving some tests to separate step in the github workflow

hoping that would speed things up (as it currently takes 15+ minutes for the GradleRunner tests...)

they're slow, but I think they're worth it. More test classes =&gt; more parallelization

<@UES7RHBDZ>
&gt; curious what kinds of APIs you have in mind?
I wrote a “improved” Gradle Runner in <https://github.com/gradle-plugins/toolbox> which try to bring some conveniences from the internal Gradle Executor in Gradle code base (<https://github.com/gradle-plugins/toolbox/blob/main/subprojects/gradle-runner-kit-api/src/main/java/dev/gradleplugins/runnerkit/GradleRunner.java>). There’s a bunch of conveniences as well as some better defaults like showing stack trace by default. One of the major goal was to treat running tests using TestKit or the Wrapper the same way. The result can be asserted via the same API. The parsing of the build result can also be compared and manipulated for better assertion (such as converting a verbose output into a “rich” output or extracting the output of a single task). This is very helpful when testing my samples or testing Gradle execution from within another tool (like Xcode or Visual Studio). These falls closely to you Builder and Truth support.

There’s also a need to something similar to your AbstractProject. To me configuring a project for TestKit or for ProjectBuilder should be very similar. I still haven’t figure out how to do it but I have various idea floating around.

I also see a lack of support for common unit test needs like accessing an `ObjectFactory` or `ProviderFactory` instance. I really like what I did with `ProjectTestUtils` (<https://github.com/nokeedev/gradle-native/blob/7dc339b659a753c46349fd3a4e405447ce19a65d/subprojects/internal-testing/src/main/java/dev/nokee/internal/testing/util/ProjectTestUtils.java|https://github.com/nokeedev/gradle-native/blob/7dc339b659a753c46349fd3a4e405447ce1[…]main/java/dev/nokee/internal/testing/util/ProjectTestUtils.java>) which saved me load of work when I enabled parallel JUnit testing on some projects but I feel some things are not in the right place still.

I find it very challenging to use ProjectBuilder for unit tests. That's one reason I generally don't bother. I'll take a look at your improved runner, that sounds interesting

facilities for easier project generation would be welcome. I myself have tried at least four times to write something generalizable. We have yet another we're working on internally, sort of along the lines of "java poet" or "kotlin poet"

Regarding slow testing, GradleRunner (aka TestKit) tests are orders of magnitude slower. In Nokee, I’m mostly focusing on integration/unit tests these days as the test time is like 45 minutes already. My general guideline goes as follow:
• Unit test can use real `ObjectFactory` or `ProviderFactory` but should avoid anything that creates `Project` or apply plugins.
• Integration test uses `Project` instance (via `ProjectBuilder`) and focus on the configuration phase. There is an unfortunate gap at this level where you can’t reliably test using `Settings` instance or `Project#afterEvaluate`.
• Functional test uses TestKit and focus on the executions.
That division should help move some tests into unit/integration testing and speed up test execution.

It’s also easy to fall into the trap of testing too much which I have done in the pass. At one point I had parallel tests that serially would take 10 hours to run… that was a bit overkill.

I would be curious to see your four attempt to project generation. That would be good learning experience. I’m sure there are some good things in there.

you can see two of them at <https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin/tree/main/src/functionalTest/groovy/com/autonomousapps>

another is the basic one in my blog post, and the fourth is an internal fixture that I can't easily share

part 2! <https://dev.to/autonomousapps/defensive-development-gradle-plugin-development-for-busy-engineers-486c>

I don't know why it is random how the failure looks like, but if you think you really need that, I guess you can make all other tasks using the service `dependsOn` the initialization task, to achieve that.

Where do you have the deadlock?
What did the thread dump say?
I'd say the only situation where this can hang is, if the runnable is not actually run.
Or do you get the output when it hangs?

Yes exactly! I don't get any output and therefore I suspect that the runnable doesn't even start running.

I am however not sure where exactly I get the deadlock. I did create a thread dump but the only thing I could interpret, was that the .get() method was waiting for a lock

<https://github.com/gwtproject/gwt-event/tree/master/buildSrc/src/main/kotlin/local>
gwt-test.gradle.kts registers a GwtTestExtension.

Thanks. This looks like it should work, but I think I have a corner case.
My precompiled plugin (`myJooq.gradle.kts`) is applying another plugin (`nu.studer.jooq`) which itself has an extension called `jooq`. I am trying customize the `jooq` extensions using my custom extension (`myJooq`) and it seems that when gradle looks for my extension it hasn’t yet evaluated the `build.gradle.kts` where I am configuring `myJooq`. Does that make sense?

ok. I figured out that I don’t need a plugin extension. I already have access to the `jooq` plugin extension in `build.gradle.kts` and I can just change it there!