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

Gradle Community

Yes, that's the same as for example for `Test` tasks.
All tests are executed even if the 2nd one failed already.

There was this issue which is heavily releated, and even goes a step further to fail parallel actions of other tasks if one already failed: <https://github.com/gradle/gradle/issues/4296>

Unfortunately it was closed by the stale bot and the two comments that were added don't have anything to do with the topic of the ticket as far as I understand them. You can comment there that the issue is still relevant and hope that the Gradle team will reopen the issue, or you could open a new feature request, maybe also pointing at the old existing one.

I think...you don't need to use withProjectDir

oh wait I misread , ProjectBuilder, I was thinking on GradleRunner

I'm checking, I think you need to create all the projects (for each level)

yeah, like:
```class Test {
  @get:Rule
  val testProjectDir = TemporaryFolder()

  @Test
  fun test() {
    val subDir = File(testProjectDir.root, "my/nested/child/project").also { it.mkdirs() }
    val rootProject = ProjectBuilder.builder().withProjectDir(testProjectDir.root).build()
    val my = ProjectBuilder.builder()
      .withProjectDir(File(testProjectDir.root, "my"))
      .withName("my")
      .withParent(rootProject)
      .build()
    val child = ProjectBuilder.builder()
      .withProjectDir(subDir)
      .withName("example-project")
      .withParent(my)
      .build()

    println(child.path)
  }
}```


Gradle does create a project for each folder, but the ProjectBuilder doesn't

ah ok, thanks! thats interesting that each subfolder needs to be a project

That's not the case. But if you include `a:b:c`, then you effectively create three projects that happen to also live in the respective directory structure by default. But you can also include `foo` and set its project directory to `a/b/c`.

I don’t quite understand what you mean <@URQ797WRW>

What do you mean by “include” (vs the original question)

If you do `include("a:b:c")` in the settings script it is the same as doing `include("a"); include("a:b"); include("a:b:c")`.
You are registering three projects `a`, `b`,  and `c` that happen to live in `a/`, `a/b/`, and `a/b/c`.
There is no project with name `my:nested:child:project`.
There is a project with name `project` that is the child of the project `child` which is the child of the project `nested` which is the child of the project `my`.
Imagine the task graph like a filesystem where `:` is the path separator.

Ok, so in the original question I am trying to recreate the gradle project structure. Therefore making each of the path segments a project sounds right?

If you don't wnat those three intermediate project, just do `include("c")` and then set the project directory of that project to be `a/b/c`.
The directories don't "have to be own projects", that just the conventional default.

&gt; Ok, so in the original question I am trying to recreate the gradle project structure. Therefore making each of the path segments a project sounds right?
Definitely, Cristian was totally right.
Just wanted to clarify on "all directories need to be own projects"

I see. Its interesting that the convention makes each dir a project even though they are empty directorys. I would have thought the minimal project needs a file.

No, a project needs nothing, it is treated as if the build script would be empty.

:100: thats the missing bit for it to make sense :slightly_smiling_face: thanks

Also in good old days it was common to configure subprojects using `subprojects { ... }` or `allprojects { ... }` blocks,
so in some projects the whole build logic was just in the root project, so no build scripts needed for the individual projects.

Which projects are part of the project is solely defined by the settings script

There's *no* way to change project properties at runtime, they're read-only.

The strategy is to have convention plugins. Each project should apply at least one plugin, which says what it _is_. This plugin would basically do what your all projects block does.

There are still situations where one needs a global thing that child things can access (e.g. <https://github.com/nebula-plugins/gradle-resolution-rules>). Something that I found to work (and what I'd like to contribute to this project) is a settings plugin. There we have access to `gradle.beforeProject` and within it we can auto-register (especially with `withPlugin`) things on the project without breaking isolation (at least so far, not sure what changes are upcoming).

What's missing from settings plugins is the generation of accessors for extensions etc. This makes them tedious to use for global configuration.

&gt; There are still situations where one needs a global thing that child things can access
&gt; 
Sounds like the need for a shared build service

Not really in the case of the Netflix plugin, no. It's interacting with the configurations and dependencies exclusions and alignments and thus needs to hook into them. I think that they found a nice workaround, but it's taxing on users. Since you have to understand that you have to apply the plugin to the root project and that child projects access the root project. Something that a settings plugin can automatically do.

That said, it would be even nicer if Gradle would provide APIs for this. Just like we now have them for JaCoCo which is a similar issue. A build service does not help here.

<@UAFGSU86M> and if you need to access to other projects outputs, for example merging some outputs in child build dirs into the root build dir, the only way is copying the jacoco aggregation approach?

I am seeing a pattern of forcing to apply a plugin in the root project, for example in Kover and nexus publish plugins. I have a plugin where I am doing that too and I would like to know how those plugins would migrate to support project isolation, cc <@UABSS056X> 

In my plugins I have two tactics. For “concentration points” I use shared build services. For enforcement of build use I have this in the top level build gradle:
```allprojects {
  afterEvaluate { Project p -&gt;
    if (p.getPlugins().hasPlugin(BasePlugin)) {
      assert p.getPlugins().hasPlugin(BaseConvention)
    }
  }
}```
where the BaseConvention is my convention plugin and BasePlugin is the Gradle one.

The BaseConvention has the following:
```project.afterEvaluate(p -&gt; p.getPlugins().configureEach(plugin -&gt; {
  Collection&lt;Class&lt;? extends ConventionPlugin&gt;&gt; conventions = KNOWN_CONVENTIONS.get(plugin.getClass());
  if (conventions != null &amp;&amp; conventions.stream().noneMatch(convention -&gt; project.getPlugins().hasPlugin(convention))) {
    throw new IllegalStateException("Cannot apply " + plugin.getClass() + " directly. You must use a registered convention plugin: " + conventions);
  }
}));```
where `ConventionPlugin` is my own invention:
```public interface ConventionPlugin&lt;T, P extends Plugin&lt;? extends T&gt;&gt; extends Plugin&lt;T&gt; {
  Class&lt;P&gt; isConventionFor();
}```


along with:
```static {
  for (ConventionPlugin&lt;?, ?&gt; conventionPlugin : ServiceLoader.load(ConventionPlugin.class, BaseConvention.class.getClassLoader())) {
    KNOWN_CONVENTIONS.computeIfAbsent(conventionPlugin.isConventionFor(), k -&gt; new ArrayList&lt;&gt;()).add(conventionPlugin.getClass());
  }
}```


FYI <https://github.com/gradle/gradle/issues/20250>

I guess I could use create configuration in `settings#buildscript` and resolve it but I don't quite remember why I switched to DRS before

Actually even using `serviceOf` already is internal API iirc

Note that it's not directly the Gradle Plugin Portal, but the JCenter mirror, which probably caches misses (IIUC, the default config should be 30 minutes, no idea how it's configured on Gradle side)
Put mavenCentral before gradlePluginPortal to avoid hitting the JCenter mirror.

&gt; Put mavenCentral before gradlePluginPortal to avoid hitting the JCenter mirror.
This requires updating all my samples to add a `pluginManagement` section :confused:

ahhhhh, and now f* restrictions of the DSL get in the way: <https://ge.micronaut.io/s/yulisrwb5vlaa/tests/:functional-tests:test/io.micronaut.gradle.aot.BasicMicronautAOTSpec/generates%20optimizations%20for%20jit%20(MINIMAL_APPLICATION)?anchor=e30&amp;focused-exception-line=0-17&amp;top-execution=1>

But that's expected if you are adding it 2 times, isn't it

define "expected". It's an arbitrary limitation from my POV :slightly_smiling_face:

IIRC, the way InteliJ IDEA does it when you want to _run_ a Java class, is to use an init-script that will register the task.

That said, I think you could resolve any configuration and get its files (stored in the `~/.gradle/caches`) and then do the copying on your side, rather than _injecting_ a task into the build.

Interesting, thank you, I'll try that approach as well

I wrote a plugin for this and already shared a gist elsewhere in this slack, feel free to borrow or steal
<https://gist.github.com/autonomousapps/f0133e58a612b6837f3f4f6554337035|https://gist.github.com/autonomousapps/f0133e58a612b6837f3f4f6554337035>

Still trying to do this from a non-plugin context in which _Project_ is not available (only _GradleProject_), but should that not work, your gist looks exactly like what I need. Much appreciated

Do you have `src/main/resources` in the project where the convention plugins code is, or in the project where the convention plugin is applied?

yes.  i always get a null back.  I suspect it probably has something to do with the classloader heirarchy and that the class loader i’m getting with `this::class.java.classLoader` isn’t the one i really want.

I asked an either-or question.
Yes is not an acceptible answer as the question was not "yes or no" :wink:

feels like an odd thing to do, but `configuration2.resolutionStrategy.force("dep1:1.4.0")`?

Yep, declare the version as "strictly" <https://docs.gradle.org/current/userguide/rich_versions.html#header>
(note there's also a shortcut notation: `dep1:1.4.0!!`)

I guess both ways (via constraint and resolution strategy) are good but constraint will be surely exposed to consumers (if you publish something from configuration2) and forced resolution shouldn't be exposed iirc

Not about the technical solution, but depending on the use case, maybe it's clearer if you have a baseConfiguration, and dep20Configuration and dep14Configuration extend from it

&gt; feels like an odd thing to do
It is `compileOnly` configuration, so it is ok to have different versions of same dependency :slightly_smiling_face:

`resolutionStrategy.force(...)` doesn't work :man-shrugging:
Using rich versions causes the resolution excepion

this worked for me:
```val whatever by configurations.creating
whatever.extendsFrom(configurations.implementation.get())
whatever.resolutionStrategy.force("org.jetbrains.kotlinx:kotlinx-cli-jvm:0.3.3")
dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-cli-jvm:0.3.4")
}```

&gt; whatever
&gt; +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.6.10
&gt; |    +--- org.jetbrains.kotlin:kotlin-stdlib:1.6.10
&gt; |    |    +--- org.jetbrains:annotations:13.0
&gt; |    |    \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.6.10
&gt; |    \--- org.jetbrains.kotlin:kotlin-stdlib-jdk7:1.6.10
&gt; |         \--- org.jetbrains.kotlin:kotlin-stdlib:1.6.10 (*)
&gt; \--- org.jetbrains.kotlinx:kotlinx-cli-jvm:0.3.4 -&gt; 0.3.3
&gt;      +--- org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.4.30 -&gt; 1.6.10 (*)
&gt;      \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.4.30 -&gt; 1.6.10
&gt; 
&gt; (*) - dependencies omitted (listed previously)


anyway I will probably go with your proposed way and will add separate configuration for this dependency that will be additionally added to compile classpath

to me it's clearer, I expect it to be used in 2 variants or just for tests, so it will show the intention better and having a named configuration it's a plus

The question is mostly, why would you need to know that? Can’t you configure the plugin in a way that it doesn’t need to figure out where it’s being run?

Why can't you apply your plugin to the app module? I guess that would fix it

The plugin adds dependencies. For AppA, moduleX needs Y but for AppB moduleX needs Z (and neither can have both)

Perhaps another plugin in the AppA/AppB modules can write to a file declaring its running? And I’d read from that. But not sure that that order is guaranteed (AppA built before moduleX)

The app itself can add the right dependency, and the modules just need to depend on a module with the interface. (Depending on the case it might be provided through DI)

thats what we do now :+1:  hoping/contemplating to break apart the app from being a so central

I was hoping gradle had a way to find out which module “started” the build, because that’ll be the one that is the target right

I guess from the outside I can add an option and pass that to the gradle command

How do you define "started"?
Is moduleX a build that AppX and AppY include via composite build?
Then you could for example indeed traverse the parent build hierarchy to look which is importing the current project.

Maybe a better solution would be if you have two feature variants in moduleX.
Each of the feature variants defines the unique set of dependencies.
Both can use the same JAR if it is actually the same code running with these dependencies.
Then AppX and AppY can select the variant they need and get the correct dependencies transitively

<@URQ797WRW>  I expect it to be different apps (maybe one is instant app and the other complete, or simply small apps consuming less modules to be used at development)

<@U02CPD9D4HF> but think on the obvious, I can run `./gradlew assemble`

Not really (I mean, your statement is still right Vampire), they can use "flavors" for that.

ah yes `assemble` still needs building without a target ofc thanks

Yes, the rootproject class loader is the parent of the subproject class loader and thus the classes on it win.
The question is, what nature is the dependency?
Is it just a "do something if plugin 2 is applied too"? If so, you can probably make it provided. If plugin 1 needs to apply plugin 2 I guess there is not much you can do on the plugin side, because plugin 1 would not see the classes of plugin 2 in the subproject.

Ah I understood you ask how you "fix" it from plugin 1, which plugin did you mean then?

Hm, I have no real idea.
I don't think there is much you can do about it from plugin2.
Where you apply plugin1 and plugin2 you can add the newer plugin2 to the class path of the root build script.
But from within plugin2 I don't think you can do anything, as the parent class loader will always win.
Except for using a different plugin ID in the newer version maybe.

I agree with the above and to add to it, changing the plugin Id will not be enough. You effectively have to change the package of the classes in the plugin JAR, otherwise classloader shadowing will still apply.

Short example to reproduce
```abstract class MyService
@Inject
constructor(objectFactory: ObjectFactory) : BuildService&lt;BuildServiceParameters.None&gt; {
    private val dep: MyDependency = objectFactory.newInstance(MyDependency::class.java)

    @get:Inject abstract val fileSystemOperations: FileSystemOperations

    fun func() {
        println(fileSystemOperations) // This works
        dep.func() // But this does not
    }
}

abstract class MyDependency {
    @get:Inject abstract val fileSystemOperations: FileSystemOperations

    fun func() {
        println(fileSystemOperations)
    }
}```

why don't you inject it by constructor to MyDependency?

Pass an instance of MyDependency (instantiated however you’d like) in as a parameter to the build service.  e.g.
```    interface GoLangToolchainParams : BuildServiceParameters {
        val cacheService: Property&lt;CacheBuildService&gt;
    } ```

normal class is my fall-back, I'm just curious on if it actually possible :slightly_smiling_face:
Really mostly just to keep the amount of code down by switching the tasks to use the same logic

Make methods instead of properties in your extension, do you can directly react and add the tasks. Or if you depend on multiple properties in combination, you could also make one method with argument `Action&lt;TheActualPropertiesHolder&gt;` and then in that method you can do the actions after all properties were configured and you can prevent the method being called again to prevent unexpected changes after you reacted for example.

Here's a bit more details of my case:
1. Objects of interest are stored in `NamedDomainObjectContainer&lt;T&gt;` 
2. New items can be added via the plugin extension `myExtension { container { register("name") { ... } } }`
3. However I'm also listening for kotlin multiplatform plugion application and when it's applied I'm using details from that plugin to implicitly create some items in that container
4. The problem is that by the time my end-user's expension DSL is evaluated, implicit items are not yet present and not retrievable via `named("implicitItem") { ... }` 

But the user also applies the KMP plugin, doesn't he? So the plugin should already be applied and your implied items present when the users DSL executes.

Yes, the user is expected to apply kmp plugin, but it's optional. i.e. items are generated if kmp plugin is applied, otherwise the user is expected to register the items manually. However if the kmp plugin is applied, the user should still be able to further configure generated items.

It's similar to how kmp generates sourceSets by targets that the user then further configures. My problem is that item generation is triggered by actions outside of my own plugin domain unlike sourceSet generation which is triggered by actions from within kmp plugin domain.

I have this hacked to work with my own implementation of lazy evaluation by registering user configs as lambdas in a list and pushing plugin config lambdas to the start of that list, then evaluating all lambdas within the list during task execution, but I'm wondering if there's a propper gradle way to achieve that.

Still not sure what your problem is.
If the user applied the KMP plugin and you reacted to that properly,
then the `implicitItem` should already be available for further configuration in the user code directly.

Unless you do something like using `afterEvaluate` instead of using `withPlugin`

I am using withPlugin, but unfortunately that's evaluated too late.

Works perfectly fine here.
Besides that `container` is an unlucky name as the container method from `Project` kotlin DSL will be used instead.
But I guess that was just an example, not the actual naming.
Can you show an MCVE where it does not work?

Lol, I've managed to spot my issue when preparing an MCVE for you. Thanks for the help!

That's one of the reasons for creating MCVEs :-)

Maybe an MCVE with what you want but does not work would help to understand

a nested extension type is no different than the extension itself - `abstract`, with managed properties.  It’s referenced in the parent extension as @Nested, e.g. (kotlin)
```    @get:Nested
    abstract val buildSettings : GoBuildSettings```
Gradle will create an instance of it when required.

Stacktrace:
```Caused by: org.gradle.api.UnknownDomainObjectException: Publication with name 'pluginMaven' not found.
	at org.gradle.api.internal.DefaultNamedDomainObjectCollection.createNotFoundException(DefaultNamedDomainObjectCollection.java:504)
	at org.gradle.api.internal.DefaultNamedDomainObjectCollection.getByName(DefaultNamedDomainObjectCollection.java:333)
	at com.gradle.publish.PublishTask.lambda$afterProjectEvaluate$1(PublishTask.java:267)
Caused by: org.gradle.api.UnknownDomainObjectException: Publication with name 'pluginMaven' not found.
	at org.gradle.api.internal.DefaultNamedDomainObjectCollection.createNotFoundException(DefaultNamedDomainObjectCollection.java:504)
	at org.gradle.api.internal.DefaultNamedDomainObjectCollection.getByName(DefaultNamedDomainObjectCollection.java:333)
	at com.gradle.publish.PublishTask.lambda$afterProjectEvaluate$1(PublishTask.java:267)```


Looks like this issue introduced with the new feature for automatic signing of plugins artifacts.

Please file such an issue on <https://github.com/gradle/gradle/issues> directly.

But if you are trying with version 1.0.0-rc-1, then it no longer supports setting `isAutomatedPublishing` to `false`, although it should fail in a more explicit way.

What’s your use case for turning that off?

One of plugins I have in project should not be published to Gradle plugins portal, and it is published only to my internal repository. So I want to disable PluginMarker artifacts creation for this plugin and configure its publication manually.

Hm.. I think I just should create separated precompiled kotlin script for this particular plugin which will not apply `plugin-publish`

Indeed :slightly_smiling_face:

Note however that having the marker published to your internal repository will allow the `plugins` notation with only an ID as long as you add your internal repository in `pluginManagement`.

Could be fixed by adding the same `override` in Task2

<@U02DF9JDXJM> did we follow up on this already?

I haven't yet created an issue, will do it tomorrow or on Monday :sweat_smile:

Created the issue: <https://github.com/gradle/gradle/issues/20550>

Solved it by converting the type to abstract class. I'd still like to hear about any proper way to achieve the same via interfaces.

Less than one week was my experience, but I don't remember the exact time.

Is this just for the first push or for every version release?

literally if you are publishing dependencies to mavenCentral at same time, they will be later than your plugin in gradle portal 

in my experience it was less than 48h for the first time, after that it's instantaneous

Accessors are only generated for things present by simply applying the plugin without further configuration. So any additional test suites you add cannot get accessors, except if you register them in some plugin you apply maybe.

Yes I know that but the  `test`  suite registered by default by the testing base plugin does not get accessors also so I don’t see the guarantee that my custom plugin will get them :thinking_face:

Ah, right. I think it only works for extensions and extensions on extensions. But `suites` is a named domain object container and I think for those no accessors are generated. Maybe good candidate for a feature request if there is none yet.

:thinking_face: Hm, I wouldve thought this would fall under “Elements in project-extension containers” mentioned <https://docs.gradle.org/current/userguide/kotlin_dsl.html#type-safe-accessors|here> where the project extension is `testing` and the container is `suites`

Usually gradle generated accessors for elements in `NDOC` if they are created/registered in some plugin that you apply. At least it was a case for `TasksContainer`/`SourceSetsContainer`. I prefer to use explicit named/by existing/by getting though.
It's not just IDE shows red but it doesn't run/compile if you try to use just `test { .. }` or `test.configure { .. }`?

Thats exactly what I am saying :slightly_smiling_face:. That `test` suite is created by the _test suite plugin_. Still no accessors generated for it. I also used `named`  to access &amp; configure it just below

Since you posted screenshot and I couldn't differentiate between absent accessors and IDE not finding an accessor. For example IntelliJ IDEA regularly loses accessors for configurations and I have a lot of red in dependencies config when really all is well

Yeah youre right <@UJUMPU407>. I also faced that issue with IJ / AS before where it doesnt index accessors or something. This screen shot was just to give more info about OP.

Just tried that. Only  `TaskContainer.test` and `SourceSetContainer.test` were generated(
And I've found no issues on GitHub either about test suites accessors or polymorphic named domain object containers.

Yeah thats the reason for my initial question. Is it by design or is it a bug somewhere in Gradle?

I guess they have to write accessor generator on case by case basis. Currently generated accessors are quite different for different containers (e.g. `*ConfigurationAccessors.kt` even have generated javadoc and generate extension methods for different receivers like `DependencyHandler`/`ArtifactHandler`/etc).

Doesn't looks like it's a bug more like just an absent feature ,)

I played with it a bit.
I think "Elements in project-extension containers" means containers that are directly extensions on the project, or are extensions on extensions, but the container has to be added as an extension.
If I for example have `extensions.add("testSuites", project.extensions.getByType&lt;TestingExtension&gt;().suites)` in a plugin, I get accessors for `testSuites.test` and `testSuites { test { } }`.
And if I have `interface Foo : ExtensionAware` and `extensions.create&lt;Foo&gt;("foo").extensions.add("testSuites", extensions.getByType&lt;TestingExtension&gt;().suites)` then I get accessors for `foo.testSuites.test` and `foo { testSuites { test { } } }`.
But `suites` is a regular property on the `testing` extension and for that no accessors are generated.

So as I said, if there is no feature request already, I guess a feature request to generate accessors for container properties on extensions would be necessary.

As far as I am aware there are none. You can look at how the docs for how the jrubygradle plugin is generated as it used jekyll, but there is no need for a global installation.

On the docker side, you are on virgin ground.

Oh well, I went ahead and published it. <https://github.com/mpetuska/jekyll-gradle|dev.petuska.jekkyll:0.0.1> is now available on gradle plugin portal if anyone wishes to try it. Key features:
• Fully wrapped jekyll cli via gradle tasks and cli options
• Managed sourceSets with an option to merge multiple directories during builds
• JekyllServe task with gradle continuous mode and hot reload support (even on container mode)
I've started using it on my own projects and it seems to be working just fine without any native bundle or jekyll installations.

Depending on what exactly you want you might get away with applying the `JvmEcosystemPlugin`. This gets you a `SourceSetContainer` and the variant derivation strategy and attribute schema of a JVM environment.

For some things idea plugin gets it itself. If it's not the case I'd suggest to react to idea plugin using `pluginManager.withPlugin("idea") { .. }` and configure required source sets. One caveat that I found is that some of their newer APIs that use `FileCollection`/`FileTree` are ignored and you have to use older ones.

See <https://youtrack.jetbrains.com/issue/IDEA-289720/IDEA-doesn't-recognize-test-sources-and-resources-set-via-IdeaMo>

```pluginManager.withPlugin("idea") {
      extensions.configure(IdeaModel::class.java) { im -&gt;
        im.module.sourceDirs = im.module.sourceDirs + extension.sourceSets.flatMap { it.sources }
        im.module.testSourceDirs = im.module.testSourceDirs + extension.sourceSets.flatMap { it.sources }
      }
    }```
Unless I'm missing something here

You can try `it.sources.sourceDirectories` in the lambdas. Another thing is to check if you need allSources instead of sources. Also check if the result type of `flatMap`s is done collection supported by the idea plugin

Verified that flatMap indeed contains my directory and is of the correct type. Still no highlighting unfortunately.

Do you have any examples of OSS project that does this succesfully?

I use it for functionalTest sourceSet since IDEA doesn't mark it as tests automatically: <https://github.com/grossws/private-repo/blob/main/build-logic/src/main/kotlin/plugin-conventions.gradle.kts#L61-L69>

Hmm, but you have luxury of having java plugin applied. My context is plain npn-java gradle scope

somewhere I had similar thing for generated sources but iirc it's not in the open source

yeah, it mostly with java/java-base in my case

Do you have directories present by the time idea plugin works on them? I saw that people sometimes add `dependsOn` for `ideaModule` task: <https://github.com/asciidoctor/asciidoctor-gradle-plugin/blob/34837b18609821bd85c239453a3111d13c1e0d0a/asciidoctoreditorconfig/src/main/groovy/org/asciidoctor/gradle/editorconfig/AsciidoctorEditorConfigPlugin.groovy#L44>

Another thing to try is to invalidate idea caches since sometimes idea just loses it

I do have directories present on init. I've tried invalidating caches, but no luck :confused:

if you have a reproducer I can try to open it in idea and look if it's the same but otherwise I've exhausted pool of ideads(

Something like `((ProjectInternal) project).getServices().get(FileFactory.class)` might work but it would use internals ,(

IIrc there is some strange behavior sometimes but it goes away if you delete the cookies or restart the browser or something like that.

what you mean with fake gradle properties 

There’s a succinct API for setting repository credentials `credentials(PasswordCredentials::class)` that will pick up the required username &amp; password lazily from gradle properties using the convention
```"&lt;repoName&gt;Username"
"&lt;repoName&gt;Password"```
Its wayyyyyyy more convenient than manually reading and setting the credentials. Unfortunately, we already have existing *org-wide* convention for providing these credentials to our builds that do not fit with this convention. Ours is sort of like
```&lt;org/team&gt;_artifact_username
&lt;org/team&gt;_artifact_password```
and is slightly different as can be supplied from properties/ env variables.

AFAIK you cannot change the convention for the API above so I’m wondering if its possible to augment the loaded gradle properties with runtime defined ones with value derived from our own properties/environment from a plugin.

you can pass properties via terminal overriding the local ones which can be fakes

Unfortunately you cannot as far as I know.
It would be good if there were for example for the Gradle properties plugin to become gradle property provider compatible.
The credentials use `providerFactory.gradleProperty(...)` so for example using extra properties will not work for that.

Sorry if I wasnt clear <@U01DUV4Q882>. I dont want to override. This is the API I’m going for <https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/repositories/AuthenticationSupported.html#credentials-java.lang.Class->

We have an internal artifactory that we use across teams teams. To supply the credentials for our internal artifactory we have had to do:
```fun ProviderFactory.propOrEnv(key: String) = 
  gradleProperty(key).orElse(environmentVariable(key))

maven("our artifactory url") {
  credentials {
    username = providers.propOrEnv("our username key").get()
    password = providers.propOrEnv("our password key").get()
  }
}```
*at every use site* across 100s of all our projects.

This API exists in Gradle and I would like to do
```maven("our artifactory url") {
  name = "ourRepo"
  credentials(PasswordCredentials::class)
}```
but it has a convention which we cannot support at the moment.

Wondering if there is a way I can supply those required gradle properties (for the example above `ourRepoUsername` &amp;`ourRepoPassword`) from a plugin so we can use the syntax above. Supplying via cmd line is not an option currently, its too intrusive

By reading this I learned about `all` vs. `configureEach`. I was using the latter for everything related to the `TaskContainer` but not for custom containers.

<@UES7RHBDZ> what do you think about `project.layout` vs. `project.file`? Any recommendations here? I’ve started only using the former.

ah, good call out. That's an example of something I should add to my "rules". I almost exclusively use `ProjectLayout` these days and always look for it in PR reviews. In particular, I heavily discourage people from using `new File()`

somewhat amusingly, I actually had occasion to use `all` just recently, in dealing with a custom domain object collection that I specifically wanted eagerly realized for use at configuration time. :upside_down_face:

the `all` vs `configureEach` is not that simple. If everything becomes lazy, then nothing realizes nothing and nothing happens. So this rule works great for _tasks_ or data which needs to be realized only if a task is going to be executed. Otherwise it can lead to surprising behavior: <https://github.com/gradle/gradle/issues/19955>

honestly this really strikes me as an API design problem. If there are container types that should be eager and container types that should be lazy, that should be encoded in the type, rather than using a common parent that can do both, and then expecting non-expert devs to remember when to use which

I agree. But I also think that the general agreement, like you wrote in your blog post, is that _everything_ should be lazy. I think the biggest problem is that nobody really knows how to make that happen.

Since the entry point of Gradle is _task names_, a lazy model which can register tasks lazily is a problem, because nothing would trigger the realization of the model.

Yeah. This came up recently <https://gradle-community.slack.com/archives/CAHSN3LDN/p1650865430773599|here>, where I ran into another surprising behavior when using `all` to iterate over a custom container for the express purpose of registering tasks _if_ some predicate were true on a given item

oh that's a different issue, the ugly "creation action" which isn't called early enough. Definitely don't like this behavior, which is counter-intuitive (and actually very problematic)

yeah, I'm really just saying I agree that not _everything_ can be lazy. When I started on that problem I knew I needed the container realized immediately and so used `create()` and `all`. Rules &lt;&gt; guidelines :shrug:

I wish some of this (excellent) advice was surfaced in the IDE itself. Something like `@DelicateEagerApi` maybe? As it is now it's really hard to remember all of it and pitfalls.

I’m personally skeptical of the “everything should be lazy” edict for speeding up configuration time. Unless you have a pre-existing issue with how long it takes to configure the build, going on a “configuration avoidance” crusade just churns the code, risking introducing new (and harder to diagnose bugs), and all for minimal gain, since you didn’t have excessive configure times before.

out of curiosity, what kind of projects do you generally work on? Android, Java, Kotlin, something else?

Moderately sized Java middleware - with bits of NPM and Docker on the periphery. I’m aware that configuration times are significantly higher for complex Android projects, and in those situations I think this is probably something worth pursuing - but I think it’s heavily context sensitive. For plugin authors I think it’s worth thinking a little about where your plugin might be used before going all in on the config avoidance. In my builds I’m looking at config times in the 10s of seconds, and assembly times on the order of 2 minutes. Full test-suite runs are 30 minutes and up. In that context investing any time in config avoidance is a false economy.

I’d trade the entirety of the config avoidance feature for a work-stealing algorithm to solve the long pole effects I see in my big test runs. That could probably save me 5 minutes on each full build.

the build I work on day to day has a config time of 90s with a warm daemon. So, every single build "wastes" 90s. It used to be a full two min. Config avoidance is a real problem for Android builds. Actually building varies by vertical, can be a couple min to ~10min. Unit tests tend to be very fast, UI tests much slower but generally only run on CI.

I can say I'd never use a plugin whose author didn't make an effort to minimize the impact on my project's configuration time.

Gradle Enterprise already supports what you've suggested: it can shard your test runs across many machines. Not sure if you're a customer

No… I get for Android that configuration times dominate, and for so for most/many plugin authors config avoidance makes sense. I just think that advice may not apply to all plugins, especially if it’s somewhat internal, and even less so for local plugins. Regarding work-stealing I really mean this: <https://github.com/gradle/gradle/issues/3955> or this <https://github.com/gradle/gradle/issues/2669>

fyi warm daemon configuration time for a typical build here are ~2s:
```$ loc
--------------------------------------------------------------------------------
 Language             Files        Lines        Blank      Comment         Code
--------------------------------------------------------------------------------
 Java                  3323       419271        61743        50937       306591
 JSON                    24        28826            0            0        28826
 JavaScript             105        20115         1915          986        17214
 XML                    115         3104          220          462         2422
 Sass                    40         2587          151          184         2252
 HTML                    33         2099          204          148         1747
 Batch                    6          939          129            0          810
 Plain Text              14          597          103            0          494
 YAML                    10          475           11           22          442
 CSS                      5          478           48           30          400
 Markdown                10          416          171            0          245
 Awk                      2          226           30           36          160
 Bourne Shell            11          236           27           99          110
--------------------------------------------------------------------------------
 Total                 3698       479369        64752        52904       361713
--------------------------------------------------------------------------------```


I'd love to see a metric like configuration time per executed task.

Just ran a build-scan over an assemble: Total configuration time 2.996s, Time spent executing tasks 2m 31.905s, 731 tasks in 115 projects

Makes you think just how heavy Android plugin must be, I wouldn’t expect under 3s configuration with over 100 projects :open_mouth: I suppose you don’t use Kotlin either?

Android creates an order of magnitude more tasks. That's why I think that it would be nice to have stats which tell the configuration time _per executed task_, and per _configured task_ (because they can be much more tasks configured than actually needed during a build). Such a stat would also give an idea if configuration time grows linearly with the number of subprojects or not. I suspect not.

Cédric, config time just running help is 90s.

are you implicitly asking about the impact of configuration on demand?

Not really. We know that configuration times are much higher in Android than they are in any other ecosystem. But we don't have a good indicator to tell if it's simply because there are more tasks _configured_, more tasks _executed_, or because Gradle doesn't scale linearly with the number of tasks/projects and ends up thrashing.

configuration is a serial process, so don't we know that, by definition, there is at least a linear component to how it scales on the number of projects?

In an ideal world, having 2 minutes configuration time is not a problem if configuration is done _in parallel_ with execution _and_ that execution time is much higher than 2 minutes. But if you have 2 minutes config time for _any_ task, even the simplest, then it's a much bigger issue showing that config avoidance isn't working as it should.

Are you suggesting that as a solution configuration-avoidance is treating the symptom, and we should be treating the cause?

I am suggesting that configuration avoidance is a required step towards interweaving configuration and execution. And that once this happens, you shouldn't suffer anymore from "long configuration times" since you wouldn't probably notice the difference between configuration and execution. It wouldn't solve, however, slow configuration, or the fact that Gradle configures too much or takes too much resources to configure. It's _simply_ a better UX because it would start working almost _immediately_.

(it's _perceived_ performance rather than _actual_)

would be nice if GE could do the data crunching you suggest out of the box. As it stands, I'd need to wade through the Export API docs and I'd still only come to the conclusion that the config time is _Too Damn Long_ (this is a US-centric political joke)

what I just learned looking at our dashboard is that there are more people running `help` than I anticipated

no. It's probably because I taught people that if they run `help`, it'll have the side effect of downloading plugins. For some reason, this step often fails during an Android Studio sync with an obscure error, but running a build from CLI is more stable

in a fully up to date build with ~200 projects, running `:foo:bar:assembleDebug` cost 12s of configuration. This involved 21k tasks

that's 0.5ms/task, that's in absolute not too bad. Imagine that interweaved with execution. Barely noticeable.

I am very excited for a future of parallel configuration. We already have our build mostly set up for it, per the guidelines currently available on the isolated projects page

For example, I see that `java-library` plugin uses first one :thinking_face:

I also don’t know what the underlying difference is, but the docs advise to use the first one
&gt; While not deprecated, it is preferred to use the methods of this interface or the `plugin manager` than use the plugin container.
<https://docs.gradle.org/current/javadoc/org/gradle/api/plugins/PluginAware.html#apply-groovy.lang.Closure->

from the code I see it is mostly the same, just `PluginManager` calls `doApply` via `apply` and `PluginContainer` calls `PluginManager.addImperativePlugin`  which also calls inside `doApply`

So seems there is no difference :man-shrugging:

Looks like legacy code that will be deleted some day so I would use plugin manager 

agreed.  though that unfortunately leaves inconsistent code:
```pluginManager.apply(...)
plugins.withType&lt;...&gt;```
…as there is no withType equivalent on pluginManager.

<@UACGKT8S1> importing `org.gradle.kotlin.dsl.apply` allows removal of ‘.java’, e.g. `project.pluginManager.apply(JavaPlugin::class)`

…and this other neat Kotlin syntax allows removing ‘project.’:
```override fun apply(project: Project): Unit = project.run { }```

…and some more DSL / extension functions on Project allow for:
```apply&lt;BasePlugin&gt;()```

<@U02S31Y7J2K> why would you want to `plugins.withType(&lt;type::class&gt;)`  vs `pluginManager.withPlugin("&lt;id&gt;")` ?

Well behaved plugins should set up some extensions or tasks or some other model and be done. You shouldnt need the actual plugin instance for anything (most of the time). Imo, its becoming _more_ consistent by recommending to use the plugin manager together with ids :shrug:

a shared build service would handle replacing the ‘rootproject’ coupling, with properties populated from the root project and consumed (as conventions) by subprojects.

Thanks, that's a good idea to investigate. It could also work with aggregation with self-registration cases like test-report-aggregation.

true.  it isn’t clear to me that subproject -&gt; root project (what you already have) is actually a coupling problem - the root project is always evaluated.  it’s use of allprojects, subprojects, or specifically coupling subprojects together that is problematic.

yeah, I still have several cases where I had to use `subprojects`/`project(":path") { pluginManager.withPlugin(..) { .. } }` pattern to allow some kind of self-registration or adding dependencies (even if dependencies themselves use correct variants)

I just migrated our plugins to use a settings plugin instead of a root project plugin and it feels much more correct. If your shared extension is anything like ours, it is very much a settings thing.

Unfortunately if I use settings plugin from private repo I have to either declare that repo in settings or move its declaration to init script which has its own issues in heterogenic environment with different private repos for different projects. And convention plugins still would need to access common configuration somewhere.

`gradleApi()` is treated specially, I believe (ditto other internal dependencies like `gradleTestKit()` and `localGroovy()`)

at least at a quick glance here, they seem to disappear from the published POM/GMM, but still resolve to the relevant files in the local distribution when used

I just got into an issue because it was pulled transitively from another module

(not using publishing so it might still be removed from the POM/GMM but looks like it's still in the outgoing variant or so?)

Besides the usual <https://xkcd.com/1172/|"it broke my workflow"> for users relying on this being in api(), what would be the downside of making it a compileOnly dependency?

`api()` is the right thing if you're publicly exposing anything based on that dependency's types, which I think a plugin is expected to do?

Mmmm fair point. Although in that case, removing it from the POM sounds counterintuitive...

I guess it's just because what Gradle wants can't be expressed in POM, but IDK why it doesn't seem to have some representation in GMM either (unless I'm missing it)