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

Gradle Community

buildSrc generates accessors so you don't have to remember the ID 

What accessors? For extensions? e.g. like applying `id(kotlin("jvm"))` gives you `kotlin {}` accessor?

Well, Gradle also generate accessors for plugins from included build or normal binary plugins, like `kotlin { ... }` you mentioned. IIRC they are generated based on registering extension no matter how exactly plugin in written.

Also for `org.example.my-plugin.gradle.kts` in either `buildSrc` or included build gradle would generate accessor so you can apply it using `plugins { org.example.\`my-plugin\` }` in `build.gradle.kts` as well as via `plugins { id("org.example.my-plugin") }`. I avoid using former variant (using accessors) since IDEA has bad habit to either insert imports for generated accessors or just break a build at inconvenient time.

Term _convention plugin_ is a bit a confusing one since some call precompiled script plugins that. As I understand plugin should be called convention plugin if it configures some defaults/conventions for your build. For example apply `java-library` plugin, configure target java version, configure publication etc. And it can be written as plain java/groovy/kotlin binary plugin or kotlin/groovy precompiled script plugin.

Sorry, slack formatting doesn't allow escaping backtick symbol in inline code. Example for plugin id accessor should be following:
```plugin { org.example.`my-plugin` }```

Yeah, my question is basically putting `my.plugin.gradle.kts` in either `buildSrc` or included build from `my-convention-plugins-module`

Mainly from performance perspective. e.g. is one of them cached better than the other in some way?

If the file is named `some-plugin.gradle.kts` , you can apply it via

```plugins {
    `some-plugin` // same as id("some-plugin")
}```

Didn't know that, but I'm not really concerned about those kind of accessors all that much.

I can't find it, hope he can share it here soon

&gt; Also for `org.example.my-plugin.gradle.kts` in either `buildSrc` or included build gradle would generate accessor so you can apply it using `plugins { org.example.\`my-plugin\` }` in `build.gradle.kts` as well as via `plugins { id("org.example.my-plugin") }`.
That's exactly not true.
That's one of the differences of `buildSrc` vs. included build.
With `buildSrc` you get the accessors for doing `plugins { org.example.`my-plugin` }`, with included builds you don't.

The other slight differences are usually more on the positive side.
`buildSrc` is always executed before your build whether you use something or not, its tests task is also always exectued (except if it is up-to-date of course), and the whole result is prepended to all build scripts of the main build.

The included build is only executed if actually used. It is only added to the build script class paths where it actually is used and only the necessary work (no tests) is done to get the jar you need at that situation. If you want the tests to be executed, you can wire them to your main builds `check` task for example.

&gt; Sorry, slack formatting doesn't allow escaping backtick symbol in inline code.
It allows, with trick 17.
Make an inline code word so that Slack already has the inline code formatting, then paste in the backtick.

Included build is better in terms of performance, it would only build required jars instead of also running tests (even with up-to-date checks it takes some time). Also you could use included build from several build but `buildSrc` could be used only from one build

<@URQ797WRW>, my bad. I quite remember gradle generated plugin accessors for included builds too but since I don't use them.. Mainly because of IntelliJ and stacking convention plugins (I have something like `java-common-conventions`, than `java-library-conventions` that use it etc), so I prefer simple `id("java-common-conventions")` syntax.

As for the trick it may work from slack on android, never tried. Usually has opposite problem with ending inline code span)

Fwiw, you would now use `project.extensions.getByType(SourceSetContainer::class.java)` (or `project.the&lt;SourceSetContainer&gt;()` or similar) for Java projects.

For Android projects, you need to first get the Android extension, something like `project.the&lt;CommonExtension&gt;().sourceSets` (or use `ApplicationExtension` if you know you'd in an Android application).

<@UDC9Q9RD0> the difference between `the` and `extensions` is it is lazy so you don't need `afterEvaluate`?

Not at all. `the()` is a Kotlin DSL extension that only adds syntactic sugar: <https://github.com/gradle/gradle/blob/v7.3.3/subprojects/kotlin-dsl/src/main/kotlin/org/gradle/kotlin/dsl/ExtensionAwareExtensions.kt#L27-L28>

Thx, which dependency do I need for that `the`  extension function?

`gradleKotlinDsl()`, which you get automatically when applying the ``kotlin-dsl`` plugin (which also applies ``embedded-kotlin``, itself applying `kotlin("jvm") version embeddedKotlinVersion` )

Great I got now the import working, next stupid question: how can I import that `CommonExtension`  or `ApplicationExtension`  classes? They are not in my class path by default

I found already the source code here: <https://android.googlesource.com/platform/tools/build/+/master/gradle/src/main/groovy/com/android/build/gradle/AppExtension.groovy>, but that link is no dependency :smile:

You need to add a dependency on the AGP (either `compileOnly` if your plugin could work without it, `implementation` if it's required, this declaration will then set a _minimum_ version, or you could use `compileOnly` anyway and let the user explicitly add the plugin to their buildscript classpath), I'd use the `gradle-api` artifact then, that only exposes public APIs.

Good so I'm on the right track. I just idenfified this dependency name: com.android.tools.build:gradle

I'd suggest rather using `com.android.tools.build:gradle-api` then :wink:

I get now a `org.gradle.api.internal.plugins.PluginApplicationException: Failed to apply plugin 'my.plugin.name'`
`Extension of type 'ApplicationExtension' does not exist. Currently registered extension types: [ExtraPropertiesExtension]`
My plugin is now basically:
```open class MyPlugin : Plugin&lt;Project&gt; {
    override fun apply(project: Project): Unit = with(project) {
        val androidSourceSets = project.the&lt;ApplicationExtension&gt;().sourceSets
        // crash in line above```

ah Javi provided the solution already I need to use `afterEvaluate`

Don't use `afterEvaluate`.
If your plugin cannot work without that plugin applied, then apply the plugin before configuring the extension.

If you just want to react if the plugin is applied, use `pluginManager.withId("...") { ... }`

`app` resolves the transitive dependencies of `library` itself, the `repositories` in use by `library` are not exposed in any way

Is there any way to tell `app` to delegate to `library` for resolving the dependencies?

So I only need to add `repositories` to my top level projects?

<https://docs.gradle.org/current/userguide/declaring_repositories.html#sub:centralized-repository-declaration>

Also is quite common to add private repo via init script if you don't want to bring it directly to your `settings.gradle[.kts]` (or `build.gradle[.kts]`). Many do so both on local developer workstations and ci servers.

Another approach is to use settings plugin to externalize repo definition. I personally use this approach lately with my own plugin published to gradle plugin repo and private repo parameters in global `gradle.properties` file (or via command line parameters on GitHub Actions).

The issue with `artifact` is that the repo it lives in is authenticated by a secret that lives in the project itself (decrypted using <https://github.com/Shopify/ejson|ejson> ).

In my convention plugin I use an ejson library to decrypt the secret when adding the repository, but my understanding is that if I use `dependencyResolutionManagement` I won't be able to use the ejson library (because it isn't in the classpath yet).

I'd rather not externalize this into a plugin or script.

you can add to the settings.gradle buildscript classpath if you want to use something in `dependencyResolutionManagement` just like in any other script

Oh interesting. I wasn't aware of that. Doing that results in `Using dependency catalogs requires the activation of the matching feature preview.`even though I have `enableFeaturePreview("VERSION_CATALOGS")` in `settings.gradle.kts` :thinking_face:

Oh looks like Android Studio showed the wrong error? I had to move `buildscript` below `pluginManagement`

What exactly do you need?
• implement `Autocloseable` so that it's `close()` method is called before it is disposed
• implement `OperationCompletionListener` so that you can use it as build event listener
• register it as build event listener using `BuildEventsListenerRegistry` so that it receives events about executed tasks and thus is required until the last task is executed
This way somewhere between the last task being finished and the build being finished the `close` method will be called which roughly is at the end of the build.

I got the first two bullets easy enough.  Is the Registration part like this?
```project.gradle.sharedServices.registerIfAbsent("myBuildService", MyTask::class.java) {}```
The docs talk about injecting the `BuildEventsListenerRegistry`  but I  haven't figured out how to do that yet.

No, that just registers the service itself as service.
Yes, you need to inject a `BuildEventsListenerRegistry` and use that to register the build service as listener.
How to do it depends on where you do it, but you basically inject it like any other built-in service you inject.

As you seem to do it from within a build script, instead of a plugin and use Kotlin DSL, it would be for example
```interface BuildEventsListenerRegistryProvider {
    @get:Inject
    val buildEventsListenerRegistry: BuildEventsListenerRegistry
}

objects.newInstance&lt;BuildEventsListenerRegistryProvider&gt;().buildEventsListenerRegistry...```

If you are doing it from a normal plugin class or similar, just define a property that gets injected.

Thanks.  I am doing it from within a plugin.  Haven't used the Property yet so still trying to figure that out.

"the Property"?
I'm not talking about the Gradle `Property` interface, but about a normal Kotlin class property

```abstract class FooPlugin {
    @get:Inject
    abstract val buildEventsListenerRegistry: BuildEventsListenerRegistry

    override fun apply(target: Project) {
        buildEventsListenerRegistry...
    }
}```

Written from mind, so might have syntax errors

Thanks.  Interesting that I have to have @get:Inject rather than just @Inject.  Some objects you can just do @Inject for example
```@Inject
protected abstract fun getObjectFactory(): ObjectFactory?```
So after I inject the buildEventsListenerRegistry,
```override fun apply(project: Project) {
    val task = project.tasks.create(PLUGIN_TASK_NAME, MyTask::class.java)
    buildEventsListenerRegistry.onTaskCompletion(task)
}```
That results in this error:
```Type mismatch.
Required:
Provider&lt;out OperationCompletionListener!&gt;!
Found:
MyTask```
where MyTask is define like so:
```abstract class MyTask : DefaultTask(), AutoCloseable, OperationCompletionListener, BuildService&lt;BuildServiceParameters.None&gt; {```


This builds... just testing it out now (took the Provider from the BuildService Registration and gave that to the OnTaskCompletion

```override fun apply(project: Project) {
        val task = project.tasks.create(PLUGIN_TASK_NAME, MyTask::class.java)
        val provider = project.gradle.sharedServices.registerIfAbsent("myBuildService", MyTask::class.java) {}
        buildEventsListenerRegistry.onTaskCompletion(provider)
    }
}```


That code builds but causes this
```org.gradle.api.tasks.TaskInstantiationException: Task of type 'com.ea.gradle.plugin.coverage.CoverageTask$Inject' has been instantiated directly which is not supported. Tasks can only be created using the Gradle API or DSL.```
Seems like I might need to split the Task from the Service and Listener?  So another class that is a BuildService and OperationCompletionListener and the task uses that new class?  :thinking_face:

&gt; Thanks.  Interesting that I have to have @get:Inject rather than just @Inject.  Some objects you can just do @Inject for example
&gt; ```@Inject
&gt; protected abstract fun getObjectFactory(): ObjectFactory?```
Because that is a getter, not a property.
You can write it like
```@Inject
protected abstract fun getObjectFactory(): ObjectFactory?```
or imho nicer and more idiomatic as
```@get:Inject
abstract val objectFactory : ObjectFactory```
Nicer especially because you can then use it directly and do not have to call the getter explicitly when using it.
But still the annotations needs to be effective on the getter, hence the `get:` which will put the annotation on the generated getter in the class file.

&gt; Seems like I might need to split the Task from the Service and Listener?
Might be, never tried to combine it like that, as that is not very OO.
It is cleaner to separate concerns and it could well be that such a combination is not supported, but I don't know.

&gt; So another class that is a BuildService and OperationCompletionListener and the task uses that new class?
Yes, that's the usual process.
While in your case the task does not use the build service.
Or at least you didn't say that, you just said you want some "build finished" behaviour.

FYI, I got this all working now.  Couple notes in case its useful:
• Any task (inherits from DefaultTask() I was unable to also make a BuildService or a OperationCompletionListener.  If all you need is to run some code at the end of a build, a task is not required most likely.  So I moved all the task logic I had into an object that is also a BuildService or a OperationCompletionListener and so runs its code at the end of the build.
• My new object, I create when my plugin is applied (i.e. instead of creating a task at this point in the plugin apply(), I create my object)
• The task I removed had an extension.  I was not able to get the task extension for configuration during my objects creation.  The extension was never populated by the gradle builds configuration invocation probably due to the order of operations between my code and when Gradle is applying the plugin.  So for now I removed the extension and used properties till I can come back to it.
• I used "project" in my tasks previously however I was not able to get that in my project via injection or parameter passing.
• The BuildServiceParams, every thing in here must be serializable.

Regarding the next to last point, what did you use `project` for?
Using `project` in tasks at runtime is also bad, especially with the upcoming configuration cache in mind where it is illegal to do so.

I was grabbing start params, project name, project dir, root project name and dir, getting another plugins setup (like Jacoco).  Using project also makes it hard to test so would love to find better ways to not need project for any future things I do.

Those things should be get from the project individually and set to separate properties, this way you don't need the `Project` instance at runtime

If you scroll down a bit here: <https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements>
You reach a table that advices on how to deal with certain things `project` is usually accessed for.

distribution_path.rb

It's just the md5 of the distribution URL

```❯ ruby distribution_path.rb https\://services.gradle.org/distributions-snapshots/gradle-7.5-20220113070244+0000-bin.zip
/Users/dannyt/.gradle/wrapper/dists/gradle-7.5-20220113070244+0000-bin/bi5rojd82o5ohh86xxikkhdfe/gradle-7.5-20220113070244+0000-bin.zip%```

IIRC I couldn't pull this off in plain bash

bootstrap-gradle.sh

Here's roughly how I used it - this was so we could bootstrap Gradle and only download Gradle once. SDKMan, gng, etc might be a better choice now - this was many years ago

Or you simply run a short gradle build while building the docker image, letting the wrapper do its work. Then you also know it is properly done.

This was for a place where we didn't have the wrapper either, but yeah, using the wrapper jar to bootstrap from a generated properties file is probably the way to go

Fwiw, on CI I just use the `gradle:&lt;version&gt;` image from Docker hub, making sure that the version matches the one from the wrapper, and then use `gradle &lt;tasks&gt;` rather than `./gradlew &lt;tasks&gt;` ; i.e. the wrapper is actually only used on developers' machines.
This is because I don't need a specific JDK, Gradle distribution, or whatever, otherwise I'd probably build a Gradle image in a similar way, and use it the same, i.e. without the wrapper.

pretriggering the wrapper, thats so smart, thanks you all!

<@URQ797WRW> btw you mean to COPY the gradle-wrapper.jar into the image and running it?

but I need to copy the whole /gradle folder (gradle wrapper.jar, and gradle-wrapper.properties) + gradlew.sh?

Well, you could probably directly call the wrapper jar without the gradlew script, but it is probably easier to just copy it along

IMO it's simpler to define a Gradle plugin in your included build. even if it's an empty plugin, you can `plugins { id("com.example.my-included-build") }` to bring the included build into the buildscript classpath of whichever projects you want to use it in

Thanks! I thought I had tried that, but I guess something was off in middle of my refactor that made it seem like it wasn't working.

right, but how do I get the path from it?

that resources property is from type AndroidSourceSet

I still do not know how to get the path from the sourceset

I found this sample, but this doesn’t work
<https://www.tabnine.com/web/assistant/code/rs/5c657fa21095a5000158356d#L93>

Ah there are two almost equal implementations:
`com.android.build.gradle.api.AndroidSourceDirectorySet` and `com.android.build.api.dsl.AndroidSourceDirectorySet`  the first one would work while the second one does not expose the file objects :confused:

One is a documented API you can rely on, the other looks more like an "implementation detail" that might change at any time: <https://developer.android.com/studio/releases/gradle-plugin-roadmap#agp_71_second_half_of_2021>

That is interesting, I was using now to get the idea the <https://github.com/androidx/androidx/blob/androidx-main/navigation/navigation-safe-args-gradle-plugin/src/main/kotlin/androidx/navigation/safeargs/gradle/SafeArgsPlugin.kt|SafeArgsPlugin>, they still relay on the internal fields

Ah the develop branch does not use the api anymore <https://github.com/androidx/androidx/blob/develop/navigation/navigation-safe-args-gradle-plugin/src/main/kotlin/androidx/navigation/safeargs/gradle/SafeArgsPlugin.kt|https://github.com/androidx/androidx/blob/develop/navigation/navigation-safe-args-[…]in/kotlin/androidx/navigation/safeargs/gradle/SafeArgsPlugin.kt>

I'd assume that they are from the same team, or work with the AGP team to make sure there won't be regressions, and have direct access to knowledge about the migration paths.

+1 it wasn't clear in the docs for me as well.

<https://docs.gradle.org/current/userguide/multi_project_configuration_and_execution.html#sec:decoupled_projects> mention that if the `allprojects/subprojects` are limited to your `rootProject` then at least configuration on demand is not affected

it is not affected because with configuration on demand the root project is always configured anyway. But if you for example have root project with child project A that has child project B. If you use configure on demand and execute a task in B, then A is not configured but only the root project and B. So if you use an `allprojects { ... }` or `subprojects { ... }` block in A where you inject configuration into B, then when using configure on demand that configuration is missing.

So if you use either of these, you automatically couple the involved projects.

Just don't do it and better use convention plugins, that also makes the build logic clearer, because you look at a build script and see all relevant logic / plugins. If you inject build logic from other projects, then you need to look around where configuration comes from.

Ok, I see better now. Thanks for the detailed answer! :slightly_smiling_face:

Well,
AS lags behind with the IJ version it uses as base,
IJ lags behind with the AGP version it supports.
...

&gt; Well,
&gt; AS lags behind with the IJ version it uses as base,
&gt; IJ lags behind with the AGP version it supports.
&gt; ...
true...
I could check it chipmunk or dolphin behave better

btw I wasn't able to google IntelliJ Android plugin roadmap/releases any page that would indicate which AGP versions are supported/expected to be supported by TK, does anyone know if there is such a thing?

If it works better, you can try using `buildSrc` instead of an included build (with exactly the same setup otherwise). Not super nice, but maybe an ok workaround for the time being.
Then, when it is working in a future version, you can just rename `buildSrc`  and include it.

Anyway, thanks for filling the bug report. I think it It is very important to give this feedback. Enabling good tool support is the main reason why Kotlin DSL exists in the first place.

&gt; Then, when it is working in a future version, you can just rename `buildSrc`  and include it.
Good point, haven't checked if buildSrc works any better. Anyway I'm fine having IJ open for gradle scripting and AS for everything else.

We'll stick with using an explicitly includedBuild as we can then have it included only when working on the plugins and use a normal repository otherwise, which shaves off a few seconds of initialization/configuration time (at least according to few simple benchmarks)

You should use custom publications instead: <https://docs.gradle.org/current/userguide/publishing_customization.html#sec:publishing-custom-components>

Do you know of a specific example? This seems like a lot to go through to simply change a version or few. The component I want to publish is the java component, just with these version changes.

Any change to a `pom.xml` file is a code smell IMO. So either it means you have custom publications and they should be modeled as such, or it means that the initial declarations were wrong. I cannot really tell from what you are explaining. Maybe there's another way for your particular use case.

Also you asked "What is the proper way" and the answer is exactly what Cédric said, fix your model so that the generated files are what you expect / need.

For the Gradle module metadata also no equivalent like `withXml` exists because you are not supposed to manipulate it but to fix your model. The only way to still hack-around (still, because `withXml` also imo is bad), would be to register some `doLast` action on the generation task that then modifies that actual generated file.

But really, better fix your model so that the generated file is what you expect / need.

The dev teams are fixing the underlying issue and as I originally said, I know that this is a workaround. Specifically, we have projects that have cyclic dependencies among them and the workaround references a previous publication, and then the local jar file on subsequent builds. This later workaround custom resolver. Unfortunately, the workaround attributes are being used in publishing the pom/metadata and needs to be corrected.
This workaround has been used for several years and has worked for our build because transitive dependencies have not been enabled. Now we are enabling transitive dependencies and the published dependencies are incorrect in this case.
In summary, I agree that there is an issue with the component model itself. But, for now it is what it is and I am looking for the best way to modify the metadata to be proper for our (probably unique) situation.

maybe publishing the resolved versions would work for you: <https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:resolved_dependencies>

That is what is already done. And this resolved version is the one that is incorrect.

instead of `fromResolutionResult()`, you could use `fromResolutionOf(yourConfiguration)`, and have your configuration something which extends, say, `runtimeClasspath`, and defines its own resolution strategy rules `configurations.yourConfiguration.resolutionStrategy { ... do the substitutions here ... }`.

This is a possibility that seems worth attempting. I will give it a try and let you know if it works for our case. Thanks

Setting up a new configuration extending from runtimeClasspath (resolved versions are used from here for the other dependencies) and setting up the proper substitution in the resolutionStrategy worked as desired. Thanks for the help

Maybe you want to also post your solution to the forum. :slightly_smiling_face:

What does the 2nd option mean? What do `bom-lib-artifact1` etc contain? I've used the 1st style for a few years now with great success.

just different parts of a library.
in the second option i would essentially be flattening out the bom-lib alongside other libs (not related to bom-lib) in the monorepo.

example: in the context of a library that uses BOM such as `spring-boot`, different components of it like `starter-web`, `starter-actuator` or `devtools`.

I see. Personally I wouldn't place any other libs that aren't part of the BOM inside the monorepo.

I think there is an issue about this but it was fixed in 7.4

I'm using 7.4-rc-2. Is it something that stable fixes?

you need to configure the test task and pass that in manually. look at the Test docs and you'll see it

Thanks. The testing docs were helpful but didn't have anything related to kts. I'll try googling a bit more later tonight

Tests are run in a separate process. You just set the system property for the Gradle process. If you want the system property to be available in your test, your need to configure that for the test task in your build script. Groovy or Kotlin DSL doesn't make much difference there.

<@U011XLJ2EAZ> see e.g. <https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin/blob/main/build.gradle.kts#L229>

The issue is this `schema.map { project.zipTree(it) }`

The map here is *not (!!)* the Gradle provider map {}. But the normal Kotlin Collections map {}. Because a configuration can be treated as a set of files (Gradle then sneakily resolves the Configuration…) this method is offered here.
This is unfortunately very easy to get wrong. :disappointed:  There is a lot of “legacy” in the Configuration API that would be nice if it could be removed.
When you call this map {}, Gradle looses all task dependency information.

Instead, you can use `schema.elements`  to get a provider for files/folder. On this you can use Gradle’s map{}.
I think something like:
`schema.elements.map { zipTree(it) }`
could work.

One note/question. You should not need:
`project.artifacts.add("schema-artifact", schemaZip)`
Is that used for something?

You already “add the artifact” by
```outgoing {
   artifact(schemaZip)
}```


Thank you, `schema.elements` brought me on the right track, just needed to tweak the `from`  of my copy/unzip task a bit, bc. `zipTree`  didn't like collections of files.
Ended up with this:
```val unpackSchemaDependencies by project.tasks.registering(Copy::class) {
    group = "build setup"
    description = "Extrahiert die Schema-Abhängigkeiten"
    from(schema.elements.map {
        var fc = project.files()
        it.forEach { fc.from(project.zipTree(it)) }
        return@map fc
    })
    into(schemaArtifactSpec._dependenciesDir)
}```


regarding `project.artifacts.add` : I need the artifact reference to add it to a maven publication, which in turn is tweaked to reference the potential schema dependencies

```val artifact = project.artifacts.add("schema-artifact", schemaZip)
project.configure&lt;PublishingExtension&gt; {
    publications {
        maybeCreate&lt;MavenPublication&gt;(KONS_PUBLICATION).apply {
            artifact(artifact)

            pom.withXml {

                if (schema.dependencies.isEmpty()) {
                    return@withXml
                }

                val depsNode = (asNode().get("dependencies") as NodeList).firstOrNull() as Node?
                    ?: asNode().appendNode("dependencies")
                schema.resolvedConfiguration.resolvedArtifacts.distinct().forEach {
                    depsNode.appendNode("dependency").apply {
                        appendNode("groupId", it.moduleVersion.id.group)
                        appendNode("artifactId", it.moduleVersion.id.name)
                        appendNode("version", it.moduleVersion.id.version)
                        appendNode("type", it.type)
                    }
                }
            }
        }
    }
}```
There is possibly a better way to achieve this, but I haven't figured that out yet :slightly_smiling_face:
Thanks again

Glad that it helped.

The publishing could be “better” modelled using a _component_ (`project.components` ).
So that the publication is only configured by `from(myComponent)` . And no direct reference of artifacts or modification of pom files.

Have a look at:
<https://docs.gradle.org/current/userguide/publishing_customization.html#sec:publishing-custom-components>

Thank you, that finally forced me to wrap my head around the components concept.  :grinning:
I almost got it working, the only thing missing is that I can't seem to convince it to produce the "type" attribute in the POM dependencies (I want `&lt;type&gt;zip&lt;/type&gt;`). Explicitly setting the type on the outgoing artifact doesn't seem to do the trick and I found no API to map a type for the Maven dependency (e.g. similar to `mapToMavenScope`)

```val `schema-artifact` by project.configurations.creating {
    isTransitive = true
    isCanBeConsumed = true
    isCanBeResolved = false
    extendsFrom(schema)
    attributes {
        attribute(Category.CATEGORY_ATTRIBUTE, project.objects.named(Category.DOCUMENTATION))
        attribute(DocsType.DOCS_TYPE_ATTRIBUTE, project.objects.named("schema"))
        attribute(Bundling.BUNDLING_ATTRIBUTE, project.objects.named(Bundling.EXTERNAL))
        attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE, project.objects.named("schema-artifact"))
    }
    outgoing {
        artifact(schemaZip) {
            type = Zip.ZIP_EXTENSION
        }
    }
}

val schemaComponent = softwareComponentFactory.adhoc("schema")
project.components.add(schemaComponent)
schemaComponent.addVariantsFromConfiguration(`schema-artifact`) {
}

project.configure&lt;PublishingExtension&gt; {
    publications {
        maybeCreate&lt;MavenPublication&gt;(KONS_PUBLICATION).apply {
            from(schemaComponent)
        }
    }
}```

well, thinking about it it seems logical that the outgoing artifact type doesn't alter the type attribute for its dependencies in the POM.
So in a way I would need to express that the dependencies of the `schema`  configuration get type=zip when writing the POM.

Why can’t you rely on the Gradle Metadata? There your variant/attributes are published and things should just work.

I think there is no API to do what you want in the POM. You would need to use `pom.withXml`  and iterate though the dependencies there to add the “type” attribute.

There is an issue for that. And I actually wrote about the workaround there…

<https://github.com/gradle/gradle/issues/3170#issuecomment-544248344>

For gradle consumers of those artifacts it will certainly do, but we'll likely have some inhouse teams using Maven. The suggested workaround will do nicely :slightly_smiling_face:
Thanks again for all the help :clap:

This is usually caused by having some other task or build logic impact dependency resolution.

I would check the output of `dependencyInsight` for that module when running it alone and with `build` as well

Tried that and it failed on this issue:
```Execution failed for task ':subproject-a:dependencyInsight'.
&gt; Problems reading data from Binary store in /private/var/folders/b8/8qkm3s6n7nb7mgt_nsz6w49400nmw5/T/gradle841480821660008144.bin offset 0 exists? true```
Can be related?

Don't apply it using plugins dsl, but the legacy way

And complain to the author to fix that incompatibility

That’s the solution I chose! Thanks!

complaint here <https://github.com/MarathonLabs/marathon/issues/602|:buildSrc:generatePrecompiledScriptPluginAccessors failing due to marathon plugin>

I don't think this is much of a configuration cache problem as no cross-project configuration happens and the project is not accessed at runtime but at configuration time.

But the idiomatic way might be a shared build service maybe.

There is no super nice idiomatic solution for some of these cases yet (I think). Especially when this extends to a composite build where you want to share a state like this across the whole build tree.

I think for caching something that is downloaded, a build service is a good solution as <@URQ797WRW> suggests.

Another is to use an extension of the root project to store some common configuration data. But this feels a bit “dirty” (because you access the root project during configuration time).

This issue is about this topic:
<https://github.com/gradle/gradle/issues/14697>

In this particular situation the idiomatic way would be to use Gradle to download the executable just like for any other dependency and cache it globally, as well as making it available globally.

The problem is that there is no such configuration included in Gradle (e.g. `exe`) that knows how to do this. The whole problem is further aggravated by the fact that executables in general are made available from random sources without metadata that would help Gradle to make it's decisions.

Maybe in this case a custom ivy with custom metadata does the trick. But, having every plugin do their own thing is not a sustainable solution. 

I started an exe plugin a while ago that builds on top of m2 repositories. I haven't worked on it for a while but it would solve the problem. Downside is that executables need to be published to an m2 repository (e.g. MavenCentral) with Gradle metadata.

note: direct access to `libs` works, so I’m missing something

Where are you calling this? It's likely you're accessing `extensions` from some `ExtensionAware` receiver rather than the `Project`.

e.g. if you do it inside a `dependencies` block you'll be looking for the extension on `DependencyHandler`, where it doesn't exist.

oh interesting point. calling from `buildSrc`!

going to double check..

I feel this too, would love to have more detailed insight into our complex builds but inhouse IT regulations won't let the scan past our proxy.

I guess an option would be to deploy a Gradle Enterprise server on-site and publish the scans there, but this comes with it's own batch of red tape issues

Heck, I'd be happy enough even having to spin up enterprise server locally and just publish to that (without any networking) just to see the scand :smile:

it would actually be nice to be able to do this, as GE customers, to capture scans when in `--offline` mode and then publish them later. Using offline for gradle-profiler helps make for more repeatable metrics, but we often want to look at scans later, especially if there were failures

`buildScanPublishPrevious` is not good enough because it only captures the most recent build

<@U022JB3L18U> did you look into the profile report? You could generate the local HTML report and get your CI server to archive it

_./gradlew build --profile_ <https://docs.gradle.org/current/userguide/performance.html#profile_report>

even after I add `com.malinskiy.marathon` to the `buildSrc/build.gradle.kts` `plugins{ }` block, it still fails

Potentially missing the repository that plugin comes from?  Does `--info` provide additional details?

Also, I'm not sure how else to get a plugin other than from the `plugins{}` block in the `buildSrc/build.gradle.kts` so that seems required in my opinion.

I was able to resolve it by:

```//apply(plugin = "com.malinskiy.marathon") // remove this
apply&lt;com.malinskiy.marathon.gradle.MarathonPlugin&gt;()```
But this is less than ideal.

Wonder if it’s a gradle bug?

&gt; I’m not sure how else to get a plugin other than from the `plugins{}`
```apply(plugin = "com.malinskiy.marathon")```
right in the precompiled script plugin^^

I think this is purely a Kotlin plugin issue. try using
```kotlin {
  target {
    compilations.all {
      kotlinOptions {
        jvmTarget = "11"```
and watch <https://youtrack.jetbrains.com/issue/KT-50115>

It’s usually a false positive due to a bug in Koltin. See workaround here:
<https://github.com/gradle/gradle/issues/18935#issuecomment-974251717>

using `project.createExtension(..)` works for extensions, but how do I generate an accessor like:


```fun DependencyHandler.`implementation`(dependencyNotation: Any): Dependency? =
    add("implementation", dependencyNotation)```


You have to create a configuration: <https://docs.gradle.org/current/userguide/declaring_dependencies.html#sec:defining-custom-configurations>

oh gotcha, if the configuration is created in the plugin then it’s automatic. nice

my issue was actually unrelated, but good to know

Sure. We have a single module depending on a library. In this library, we apply a precompiled script plugin. Everything is working fine.
However, when developing, some team members are using the ‘includeBuild’ feature to include this library, so that they can always have the latest version, make code change in it without rebuilding it.
With this configuration, the resolution of the precompiled script plugin in the included library fails with: ‘plugin is not in org.gradle namespace. 

Does dependent project have `includeBuild` for both library and its included builds?

Not quite sure I get your question, but if the question is: does the project also includes the aforementioned library in its dependencies section in addition of the includeBuild directive, the answer is yes.

Ok. I got it. This library is itself a sub module, so we can't give the plugin a version since already applied on the parent.
If I explicitly give it a version, it resolves without issue ( but will fail building the other project saying that ´ plugin request for plugin already on the classpath must not include a version’) This was fixed in 7.4, right?

iirc it only changed if the version to be applied and the version on the classpath are exactly the same, though I might remember wrongly.
I'm still not 100 % sure I fully get your situation.
Can you mayb knit an MCVE?

See <https://github.com/ask4gilles/gradle|https://github.com/ask4gilles/gradle>

Urgh, never use a project as subproject *and* separate build.
`subproject-api` is used as subproject of `subproject` and as subbuild of `main-project`.
Instead include the `subproject` build from `main-project` and remove the settings script from `subproject-api`.
Alternatively also use `includeBuild` from `subproject` to `subproject-api`.
The `subproject` build defines `mavenLocal()` as plugin repository, the `subproject-api` build does not.
So when you include `subproject-api` from `subproject` the plugin is available, but when you include it as subbuild from `main-project`, the plugin repository definition is missing as you don't have it in the settings script of `subproject-api`.
You could of course also define the plugin repository in the `subproject-api` build and indeed if you decide to go the route to also `includeBuild` `subproject-api` from `subproject`, you even have to add it.
But please don't just do that, as it is just not the same if you one time use it as subproject and one time as subbuild.

Thanks for looking at this.
This dependency model is indeed a design flaw that we should get rid of.
But for the time being, we've to deal with it.
There are several elements in your answer and I’m a bit confused on the best way to fix this…
Would you mind pushing your best proposal on a branch when you have time?

&gt; This dependency model is indeed a design flaw that we should get rid of.
&gt; 
What do you mean? As described, the major flaw is that you use `subproject-api` as subproject in one project and as separate subbuild in the other. There is nothing that should be able to force you to deal with it instead of fixing it. As described, use it consistently, either as subproject or as subbuild.

&gt; I’m a bit confused on the best way to fix this…
&gt; 
There is no "best" way, there are just alternatives and what is the best depends on your situation and what you want. But I guess my first suggesting could make sense, that's why I made it first and just provided you with an alternative.

What is unclear with
&gt; Instead include the `subproject` build from `main-project` and remove the settings script from `subproject-api`.
&gt; 
?

&gt; Would you mind pushing your best proposal on a branch when you have time?
&gt; 
Not at a computer right now and "best" is a matter of opinion. But I think you should be able to change one method call argument and delete one file. :-)

Depends on what you mean by "specify" and what you mean by "inherit".
If your plugin adds those dependencies to the project it is applied to, then the dependencies are on the project where the plugin is applied to.
If your plugin code has dependencies that it needs for its work, then the projects you apply it to will of course have them in their build script class path so that the plugin can work, but of course not in its production class path.

The first scenario can be split in two:
• Your plugin adds production dependencies to the project it is applied
• Your plugin defines extra dependency configurations and use those to run its custom tasks.

Mine is the first scenario, I’m basically just trying to encapsulate a set of dependencies within a plugin.

Reason being is that I have generated projects that are updated by dependency bots and updating ~20 dependencies per project is painful.

Yes, you can do that. Or you could also publish just a version catalog and use that in your projects

Untitled.txt

This is what I had to get it going.  I had a different issue with it complaining about a "duplicate class" but maybe this helps you.  This is right out of their docs.

Mine includes the test report aggregation which does work for me

The above is in its own sub project called "test-results" as well.

Thanks, I see what has happened. I was following the example here: <https://docs.gradle.org/7.4-rc-1/userguide/jacoco_report_aggregation_plugin.html#manual_report_creation>

Yah I used that as well.  I only tried on the rc-2 however in case that changes anything.

ok I don’t get a build error but every time I run the task I get `Task :aggregateCodeCoverageReport SKIPPED`

What are you really try to do actually?
Because you say "how to do aggregated JaCoCo report", then you show how you try to register a report for aggregated test report (which is also the cause the error complains that the report type is not known), and then you complain that the JaCoCo report task is skipped.

I am trying to create an aggregated Jacoco coverage report which can then be consumed by sonarqube and jenkins. Similarly I would liket o create an aggregated test report which can also be consumed by Jenkins.

It seems the aggregated test report can only be html (not xml).

&gt;  I am trying to create an aggregated Jacoco coverage report
Why I asked is because you apply the plugin for jacoco aggregation and then try to register a test aggregation task which is why it does not work.

&gt; which can then be consumed by sonarqube and jenkins.
Afair those reports are HTML report, so not for consumption in SQ or Jenkins.

I didn't use those plugins yet, but from a quick look, I'd guess the `jacocoAggregation` configuration will contain the XML files that you then configure SQ and Jenkins to process.
Both tools should be able to process multiple report files, otherwise you need a `JacocoMerge` task that merges them.
But that task type is deprecated as virtually any tool accepting JaCoCo reports support processing mutliple files.

&gt; Similarly I would liket o create an aggregated test report which can also be consumed by Jenkins.
&gt; It seems the aggregated test report can only be html (not xml).
Same as above.

Hi. Your source set is defined as:
```resources {
    srcDirs = ['src/resources']
}```
`main` is missing.

But those `sourceSets` definnitions are not needed for `java` plugin. Except the `'src/test/config'` which is not defined by default.

Well, there is even more unnecessary configuration besides most of the source set configuration.
The spring boot dependency management plugin is applied without using it and actually it is imho better to use the builtin BOM support, the `bootJar` gets a classifier configured though it gets disabled, why is the boot plugin applied at all if then the boot jar task is disabled, the classifier of the jar task is configured to its default, the resources already packed into the jar because they are in the source set are again explicitly configured to be packed, for tests first JUnit 4 is configured, then immediately changed to JUnit 5, ...

Thank you <@U02L3RD6ESY> and <@URQ797WRW>. I corrected resources configuration. Regarding spring dependency management plugin i removed it. However regarding boot jar plugin i added to generate build info while along with jar file. I removed junit4. All of these i was added because spring internationalisation is not working.

I see, but maybe a bit overkill to apply the boot plugin and then disable its main outcome just for generating a properties file. :smile:

they’re “poll only”, I want to do say `property.whenSet(Action&lt;T&gt; doThis)`.

unless I’m missing something that is…

Ah, I see what you mean. No properties cannot do that of course, because they could also be reset again and their sense is to evaluate them at usage time so that all configurations are done already.
So I guess we are back at having setter methods so that you can react to those being called.
The setter method then can of course configure an internal property that you maybe expose as provider for re-wiring for example.
Something like that.

try to run with `--scan`, it will tell you why the tests were executed. By default Gradle will _not_ rerun the tests if nothing changed (unless the previous test execution failed)

Do you think these count as errors for it to trigger tests again

the TEST is not failing per say but this error is logged

don't look at the test results, look at the test _task_ and it will tell you why it was executed

eg similar to this <https://ge.micronaut.io/s/v6uy322gkjkxe/timeline?details=g2dd7entuuy7i&amp;task-path=test>

It gives below info, but when I went to that path and checked the folders and file are present.

I just did build and my build.gradle has this

I suspect you have a plugin which breaks this. The warning about overlapping outputs is curious. So my educated guess would be that you have a plugin which deletes the test results and does something to the test tasks.

but thank you for all your inputs, i’ll investigate further in this direction

<@UAFGSU86M> I keep getting build-info.properties has changed and hence test task is not up to date

If you generate that file with a unique build identifier, then it makes the task always out of date.

Have a look at docs as there are different strategies to fix that.

<https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:up_to_date_checks>

Thank you all for your help. I am able to achieve what i wanted

Maybe if it is in `buildSrc`, what's your plan?

yep it’s in `buildSrc`. How would that differ between regular projects?

Ah, I meant if the class to be used is in `buildSrc` and you use it in your regular build in the build script

Within that one file it will probably not work. The `buildscript` block needs to be evaluated separately first as it defines the class path to build the rest of the script file, so you cannot use the class that is defined in the rest as the rest is not compiled yet and cannot before the buildscipt block is already evaluated.

Asking for a friend: what do you want to do with it? :slightly_smiling_face:

Because if you for example want to use it to set some project value you might be in the correct scope to get one in the setting part for example, like
```gradle.rootProject {
    layout....
}```