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

Gradle Community

What does your "bootstrap" task do?
How about `tasks.configureEach { dependsOn(tasks.bootstrap) }` ?

We are not planning a 7.4.3.  I would love to see your "bootstrap" task in full.

<@URQ797WRW> we've actually talked a bit about this... <https://gradle-community.slack.com/archives/CA7UM03V3/p1649277324153979>

<@U03AFQVC16K>: the bootstrap task is mainly something that can run a bunch of other tasks but that is always run first even if you're running on the command line or in the IDE.  Stuff it currently does:
• make sure all versions of AS/IntelliJ on the system are configured correctly (this includes enforcing plugins are installed or removed, setting up configuration files in .idea, setting up the VMOptions for the heap size, setting up the correct JDK to use so IDE/command line use the same one, setting up IDEA settings, etc.)
• configure iterm2
• configure ~/.gradle/init.d scripts
• configure .gitconfig
• configure Flipper and its plugins
• downloading artifact JAR files
It's basically to make sure a developer's environment is perfectly set up.
I think if we could get bootstrap-init.kts to run a task instead of just inline groovy, it would probably also work, but AFAIK, that's not possible.  And this bootstrap plugin/task is specific to our project while bootstrap-init.kts is run on any gradle project on your machine.

For 7.5, the code we have in 7.4 to add this initial bootstrap task causes a stack overflow...we do this:
```gradle.taskGraph.whenReady {
    withGroovyBuilder {
        val executionPlan: ExecutionPlan = getTypedProperty("executionPlan")
        executionPlan.addEntryTasks(listOf(taskProvider.get()))
        executionPlan.determineExecutionPlan()
    }
}```
I'll see if we ever opened up an issue for this...

doing a lot of similar “setup dev environment” work via init scripts without tasks.

with parts of that work in convention plugins (e.g. golang plugin that sets up golang dev environment)

How do you control the init scripts and share setup code across projects?
We also have convention plugins FYI....lots of them....

init scripts are part of a custom gradle distribution.  though, if that’s not doable, you could distribute them into a private repo and have a convention plugin that grabs them and updates them into ~/gradle/init.d.

most of our “dev environment standardization” is a combination of init scripts + a core plugin, with some tech-specific pieces thereafter via other convention plugins (e.g. the golang stuff).

&gt; have a convention plugin that grabs them and updates them into ~/gradle/init.d
Doesn't this happen too late?  i.e. we'd like all of this set up before the convention plugin runs...
I think your method is working for you because you have a custom gradle distribution...so you solve this chicken vs. egg thing by doing this :slightly_smiling_face:

It works for updating scripts, though they won't take effect until next execution.  Yes, we ended up with custom distribution to cleanup cyclic dependencies.

so hypothetically, if you could insert a "bootstrap" task in place of all your init.d scripts, would you? :slightly_smiling_face:
We did it because it lets our bootsubtasks run in parallel as well as take advantage of config caching...
You wouldn't need your custom gradle distribution I think...

Unlikely.  Currently most of the setup is quick enough that time isn't a material factor.  If we did need to address that would use a build service.  Would still keep custom distribution for other reasons.

<@U03AFQVC16K>: repro for the 7.5rc1 issue I mentioned if you can nudge some folks to have a quick look before 7.5 is released :slightly_smiling_face:
<https://github.com/gradle/gradle/issues/20940>

Thanks Ken! I will have a look and push accordingly :wink:

Nothing built-in, but there are various plugins about versioning, depending on what exactly you actually need.

Do you also have other skipwhenempty inputfile properties?
iirc the task is only skipped if all of them are empty, but I might remember wrongly.

interesting. you _seem_ to be right as it is working now. Didn't think about that and havn't found any documentation for that behaviour. thx

In the table with all the annotations:
&gt; Used with @InputFiles or @InputDirectory to tell Gradle to skip the task if the corresponding files or directory are empty, *along with all other input files declared with this annotation*.
&gt; 
And in the JavaDoc of the annotation:
&gt; If all of the inputs declared with this annotation are empty, the task will be skipped with a "NO-SOURCE" message.

It's like me asking in the super market "where did you hide product X now?" and the employees lead me to the place where I looked 5 times already. :smile:

This is not a Gradle problem. You start `java.exe` and it quits with exit code 0xC0000409 (-1073740791).

It's easily possible, but trying to do so sounds like a code-smell already.
But you can easily check whether the `rootProject` has `subprojects`.

Agreed on the smell.  Just trying to prove some stuff out and what not.

For a particular dependency, just use a forced version if you are not in the scope of a library.

If you want it for a whole lot of dependencies like in that example it is probably better to just depend on the respective BOM or if none exists, create a virtual platform to align the versions as described at <https://docs.gradle.org/current/userguide/dependency_version_alignment.html>

i'd like to ensure same kotlin version
there are known issue with different versions for kotlin-stdlib and kotlin-reflect, which I try to avoid the following way:

```root build.gradle


configurations.all {

resolutionStrategy.eachDependency { DependencyResolveDetails details -&gt;
        def kotlinVersion = libs.versions.version.kotlin.stdlib
        def requested = details.requested
        if (details.requested.group == 'org.jetbrains.kotlin') {
            List&lt;String&gt; list = ['kotlin-stdlib', 'kotlin-stdlib-jdk7', 'kotlin-stdlib-jdk8', 'kotlin-stdlib-common, kotlin-reflect']
            if (list.contains(requested.name)) { details.useVersion kotlinVersion }
        }
    }

}```
the question - is that well enough or there are something "bad" and nobody does like that anymore?

Just as I said, use the Kotlin BOM to align the versions and a forced version to ensure a specific version if you are not in a library project.

(here is the message with tons of dirty words)

Honestly, it's scary a little because you have never seen my code and instantly give me a solution!!

I just know how to interpret the error message. :slightly_smiling_face:
&gt; ```Could not set unknown property 'dependencyResolutionManagement' for settings```
Means you have `dependencyResolutionManagement = ...` in your setting script and there is no valid syntax like that

And you are not the first using an equals sign in similar cases

It was still creepy :smile: thx a lot Mr. Nostradamus!

Well, you can alternatively assume I quickly hacked into your box and looked at your sources if that makes you feel more comfortable. :smile:

Can you do it one more time and give a hint about it, please? :slightly_smiling_face:
&gt; A problem occurred evaluating settings ‘service-name’.
&gt; &gt; Could not find method dependencyResolutionManagement() for arguments [settings_5gr6kuukez26uvchtedabbm6q$_run_closure1@2612610] on settings ‘service-name’ of type org.gradle.initialization.DefaultSettings

that's an annoying category of error messages which can be difficult to debug even with the code available. but in short you need to make sure everything inside the `{}` is all valid - the error means there's something in the closure that Groovy decides makes it not applicable. (one massive benefit of using the Kotlin DSL is that this can't happen)

Is this type of error when you see smt like this in logs "hey, bro! here is an error, have a nice trip with investigation!"?

Actually as far as I remember in Gradle 7.5 they fixed something that hopefully reduces such error messages and shows something helpful instead.
But yeah, these error messages are one of the reasons I exclusively use the Kotlin DSL nowadays wherever possible.
If you want to stick with Groovy DSL, comment out the whole content of the closure and then comment it in part by part to find where you used wrong API.

I've commented absolutly all content inside:
```dependencyResolutionManagement {
    versionCatalogs {
        libs {```
and it's failed with the same error.
I try integrate `dependencyResolutionManagement` in a project which already works well with dependencies so I just try to improve dependency control here.
Probably, smt in the build.gradel files affect  `dependencyResolutionManagement` . Interesting.

No, you just didn't comment everything. If you would have commented everythign you would have found that it is the `versionCatalogs`.

is it possible to achieve the same with a pure java project?
can i define a constant in my groovy gradle file that i can import into my kotlin code?

many many many ways. <https://plugins.gradle.org/search?term=buildconfig>

Or simply a task of type `WriteProperties` that produces a properties file you can then load from your code.
Or a `.properties` or whatever file with placeholders in your resources where you fill in the placeholders by configuring the `processResources` task.
As <@U019L3NM4PK> said, many, many ways.

thanks :smile:
i am property file "Averse" !!!

Then generate a YAML file or JSON file or whatever you like, doesn't matter.

The principle is the same.
Either have a task that generates it,
or have a version with placeholders in the resources that you then replace

generating source code for primitives isn't hard either, just have to take some care with strings

While I personally would not generate code if not really necessary, especially if it is the only generated thing.
Because you then always have the problem that a fresh checkout, or a web view does not have the generated code,
which typically is more disturbing than a missing resource file.
But yes, generating code would also be possible.

i do lile the YAML idea, i have successfully employed it in other projects
im not sure why i like YAML and not property files though :thinking_face:

especialy this  "`com.github.bmoliveira:snake-yaml:v1.18-android`"

Android unfortunately makes Java resources rather terrible: <https://github.com/FasterXML/jackson-core/pull/49|https://github.com/FasterXML/jackson-core/pull/49>
so on that platform, it is far better to use native Android res or code generation than to generate a properties or YAML file in resources

that's true. although if you are using targeting Kotlin Multiplatform, there's no Java resources on native or JS either

Ok, let me rephrase and quote. He specifically asked "is it possible to achieve the same *with a pure java project*y?" :slightly_smiling_face:

"pure java" and "kotlin" in the same message, so I assumed from the start that they were not consistent in what they are asking for

as i am not familiar with kotlin gradle dsl I used "pure java" in an attempt to obtain a groovy gradle solution and to signify this is not an Android project
i am in fact creating a kotlin code generator application using kotlinpoet, and *not* an annotation processor, gradle plugin, or android app.
the groovy gradle solution to my issue would not be affected by the language i am developing in(?):thinking_face:

I would always use Kotlin DSL actually, as you get type-safe build scripts, better error messages, and muuuch better IDE support.
And yes, the language you use in your build scripts is absolutely independent from the language you use in your production code.
But using "pure java" as synonym for "Groovy DSL" is actually pretty strange,
as Groovy is not Java and it more sound to me like you talked about your production code, especially as you cannot write a build script in Java. :smile:

Why wouldn't you use the merge strategy and define the constant along src/{flavor}/java?

You would’ve been the original poster. Not sure why but the second post didn’t show on my phone but did now. My post is moot.

For a pure Gradle project with no AGP, you’d have to go the route suggested for a YAML file.

You _could_ do something else, but our team has had a strong opposition to generating things in build scripts using build scripts (as in the original snippet) but rather based on using AGP’s merge strategy.

1. Verify you opened the correct directory
2. `File &gt; Repair IDE` have IntelliJ fix the problem for you

0. Provide the complete error message and more context information

```Directory '' does not contain a Gradle build.

* Try:
&gt; Run gradle init to create a new Gradle build in this directory.
&gt; Run with --stacktrace option to get the stack trace.
&gt; Run with --info or --debug option to get more log output.```

Thank you for the reply, I used Repair IDE and Invalidate Cache but the problem is still persisting

If all else fails, close the project, delete the `.idea` folder and reopen the project.

Gradle itself does not use Log4j 2 and whatever project you have it should not include Gradle and thus is not subject to the vulnerability just because Gradle has Log4j 2 somewhere in its transitives references. Well, unless I understand something wrong in your description. :wink:

Check out <https://blog.gradle.org/log4j-vulnerability> for more information.

Thank you for your reply!

Whenever I run a gradle sync, these files are appearing on my workstation. 
user/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/

This means that at some point, the gradle is using the log4j 2.10, and a hacker can run the RCE on my machine at this time. When I run a gradle sync with gradle version 6.9.2 it shows the log4j non vulnerable version 2.17.

Sorry for sending a picture instead of screenshot, my workstation is highly secure and can't run slack on it

This means that something depends on it in your project, that is why it shows up in the cache. That does not mean that it is being called, and it most certainly does not mean that someone can call it from within Gradle since the cache is not the classpath of Gradle.

You can `rm -fr ~/.gradle` and import your project from scratch to see if it shows up again. Maybe this is just a left over from some build you ran months ago. It’s generally good practice to not wipe this stuff locally for optimal build performance across projects, but if you want to be absolutely certain that Log4j 2 does not show up anywhere, this is a way to go.

My project is not using log4j at all, I ran a dependency report on it. This path in my workstation is the .gradle general folder, not the project related folder. Thank you for your reply

Just so that you have two voices: what <@U01A244DYUF> said

Gradle uses a global cache for all projects you build to speed everything up. Also, while your project might not include Log4j in its dependencies (and thus nothing shows up in the dependency report) does not mean that there are no Gradle plugins that depend on it.

If it lands in that cache, either your project or maybe some Gradle plugin you use uses it.

The things Gradle itself uses are pre-shipped and not downloaded to any cache

As you are in high-secure, I guess you cannot create a build scan?

Thank yall for your reply! I'll double check if there is anything on my workstation that is using the log4j

If so you could at least use `dependencies` and `buildEnvironment` tasks to find where it comes from

Something I noticed, is that when I update my gradle to 6.9.2, log4j in that specific folder appears as 2.17, which is nice but affects the app stability

You mean that your build breaks, because Gradle cannot affect the stability of a running app, since it’s a build tool. My only response to this, which might sound harsh but is the only possible response given the “high security” + “human lives depend on it” context: Always upgrade, everything, all the time, everywhere. It’s the only way to ensure safety and security. (Check checksums, verify signatures, … also for Gradle plugins.) Not doing so in this context is, well, reckless. Again, I don’t want to be harsh, and sorry to be so frank, but this is how it is given the context.

The Log4j you see might be from the Scala plugin, in case you use Scala. That’s the one explained in the Gradle blog post I shared.

Don't worry, I totally get where you are coming from, but it isn't up to me to decide that HAHA I guess my company doesn't want to invest months worth of salary to upgrade the gradle. And, when I mean stability, I mean updating all the dependencies, layouts and anything that's involved with updating a gradle

Jumping from 4.1 to 6.9.2 is definitely going to be cumbersome since you jump over 2 major upgrades. I’m not surprised. :disappointed: The thing is that you might not even be able to update whatever pulls the vulnerable Log4j version, since it’s probably a Gradle plugin and newer versions require a newer Gradle version.

What you definitely can do is to force upgrade Log4j in all places. Gradle 4.1 is long ago for me, but something like the following in your `build.gradle` should do the trick:

```buildscript {
  dependencies {
    classpath("org.apache.logging.log4j:log4j-core:2.17.2")
  }
}

configurations.all {
  project.dependencies.add(name, "org.apache.logging.log4j:log4j-core:2.17.2")
}```
This basically adds Log4j core with the latest version everywhere and thus forces resolution to this version. This is brute force and most probably has unwanted side effects, but it should work. Newer Gradle versions have better APIs to do something like this, and maybe Gradle 4.1 had some of those already too, but, as I said, Gradle 4.1 is way back for me, so I don’t remember.

Urgh, why should he add log4j-core to everywhere even if it is not there already?
At most add a constraint, or just use the recommendation from that blog entry.

Anyway strange if a Gradle plugin depends on `log4j-core` at all, that's imho a bug per-se

I really don’t know what kind of APIs Gradle 4.1 had to offer, as I wrote above, the example code is going to lead to unwanted side effects. Maybe you remember 4.1 better and can provide a better code snippet.

<https://docs.gradle.org/4.1/userguide/dependency_constraints.html> &lt;- 404 this page does not exist :disappointed:

<https://docs.gradle.org/4.1/userguide/dependency_management.html#sec:finetuning_the_dependency_resolution_process> :thinking_face:

thank you for your replies, I had no idea how that cache folder was generated with the log4j

so, it could be a plugin issue in the project gradle files right?

&gt; so, it could be a plugin issue in the project gradle files right?
I already told you how to find out, you just ignored it. :wink:

<https://gradle-community.slack.com/archives/CAHSN3LDN/p1654622035642049?thread_ts=1654619821.903759&amp;cid=CAHSN3LDN>
I got it! thank you :slightly_smiling_face:

hey yall! I was able to get rid of this log4j in the project so easily! I can't thank yall enough for this knowledge, I had no clue

:til: how cache files are generated by the gradle

&gt; of _generating_ a catalog from an existing bom
A BOM is conceptually very different to a version catalog. A BOM is conceptually equivalent to a platform. It influences resolution, can control transitive dependencies, the dependency on it can be published as part of your metadata, ... A version catalog is as its name states just a catalog of libraries, plugins, and versions your build scripts can pick from which is absolutely transparent to downstream projects or resolution engine.

&gt; but as far as i know, i cannot consume &amp; expose catalogs A, B FROM my own catalog C.
Why not?
```versionCatalogs {
    create("C") {
        from("A")
        from("B")
    }
}```
&gt; it seems like it would be feasible to  programmatically generate catalog entries from existing BOMs allowing for the type-safe / autocompletion benefits, without waiting for say, the spring-boot team (:smile:) to provide a native catalog
I guess they are just too conceptually different to do that in any good way. For example would you then just have the coordinates without version? Or with version too? Or ...?
You could maybe write a plugin that does it for you how you think you need it and makes sense. :slightly_smiling_face:

Or you can post a feature request to GitHub for the consideration of the Gradle guys if you really think this is something Gradle should support built-in.

IIRC you can use from only once in catalog definition

ideally i think every platform would have a corresponding catalog. when you’re using a catalog, you’re by definition getting all of its declared dependency versions (as recommendations at least) so having a corresponding catalog without versions makes sense to me.

micronaut for example does this, and publishes the the catalog alongside the platform (BOM) <https://melix.github.io/blog/2022/02/micronaut-version-catalog.htmlp>

unless i’m missing something it seems like this would be _feasible_ to do for any _arbitrary_ bom.

&gt; IIRC you can use from only once in catalog definition
&gt; 
Oh, really?
I didn't try it, but the JavaDoc of it made me think it should work.
&gt; unless i’m missing something it seems like this would be feasible to do for any arbitrary bom.
&gt; 
Quite possible. As I said, you should maybe open a feature request about it.

Note that the micronaut example is solely about providing type-safety (and IDE completion, where available) for references.  As they publish a BOM, the version numbers for components are not required (as shown in their examples).  It would make sense to do it in this manner (without versions); adding versions into a generated-from-BOM catalog is unnecessary and adds a layer of confusion.

…and the type-safety is only available for Gradle Kotlin DSL (Groovy isn’t type safe).

<@URQ797WRW>, I remembered correctly, Gradle has relevant guard both for several imports and one import from several files: <https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/src/main/java/org/gradle/api/internal/catalog/DefaultVersionCatalogBuilder.java#L252-L263>

So I don't think auto-generating catalogs from BOMs is a good idea. We considered this in the past, but there are several problems with it. First of all, BOMs and catalogs serve, as described in this thread, different purposes, but that's not a blocker. BOMs, however, are "Maven-centric" in the sense that their model is the one from Maven. They use GAV coordinates and properties. Catalogs use GAV coordinates, properties, and aliases. This means that if you use a BOM to generate a catalog, there's one piece of information missing, that you have to generate: an alias. Automated aliases are doable, say if you use the artifactId, but it's a poor man's solution and can lead to non user friendly aliases or conflicts. That's why Micronaut takes the other approach, which is to generate a BOM from a catalog. It even composes catalogs by inlining aliases from other catalogs.

As for composing catalogs when importing them in Gradle, as you noticed, this idea was dismissed (see <https://github.com/gradle/gradle/issues/20383> for discussion)

<@UAFGSU86M> thanks so much for the response!  i agree about the auto-generated aliases, though, i am not sure that referencing an autogenerated alias `implementation(<http://libs.org|libs.org>)` is in any appreciable way worse than the traditional string version of `implementation(org.springframework.boot:spring-boot-starter-web)"` and could in some cases be preferable (users don’t need to learn new aliases, they just get autocomplete on the gavs they may already be familiar with)

I also agree that micronaut’s approach is of course preferable, but i hate to say that this seems like another example of gradle refusing to meet users where they _are_ - and valuing the ideal over the pragmatic (see ability to centrally overriding bom properties ala spring dep mgmt plugin). In an ideal world all 3rd parties would follow the approach micronaut took, but we don’t live in that world. IMO it’s best to strive to make the end-user experience more “good” than to say there’s nothing that can be done until upstreams get their shiz together.

Re: composing, i (surprise!) also think that is the wrong choice from a user’s perspective, of course the code-defined workaround is fine for self-managed catalogs, but stinks for combining self &amp; third party into a single consumable (i.e. single enterprise-wide catalog that composes internal &amp; 3rd party ).

Could you possibly link me to the micronaut code that handles the catalog inlining?

<https://github.com/micronaut-projects/micronaut-build/blob/master/src/main/groovy/io/micronaut/build/MicronautBomPlugin.java#L340-L369>

regarding "not sure that referencing an autogenerated alias implementation(<http://libs.org|libs.org>) is in any appreciable way worse" you have to remember why catalogs were introduced. Basically to avoid having to remember GAV coordinates, so if you have to know them to know what to type, then it kind of defeats the concept. That said, I'm sure somehow can hack a settings plugin which converts a BOM into a catalog. Should be quite straightforward (except for parsing the BOM and its parents).

&gt; this seems like another example of gradle refusing to meet users where they _are_
Could well be and some of these occurrences are really unnerving like "optional" support and similar.
But if Gradle would just meet the users where they are, we would not have the amazingly great new build tool Gradle is,
but a Maven clone that helps noone.

If configuration allows to read constraints than reading bom or platform could easily be delegated to gradle via resolvable detached configuration. I'm not sure if there's public API to do it

For me absence of `optional` is much less painful than absence of `provided` in non-war environment. Maybe because I write agree with Gradle team about fallacy of `optional`.

isn’t `provided`satisfied by `compileOnly`?

The `optional` was just one example where it needed ages until the Gradle guys came up with a proper solution and refused to do a pragmatic but unclean intermediary solution.

And yeah, what is wrong with `compileOnly`?
Just that it is not added to the POM?

I agree not having to remember _is_ a big plus… but at least a generated autocomplete is _more_ discoverable than a string. The autocomplete can help guide you, even if not as optimally as with a nice human-considered alias.

I definitely wouldn’t advocate for a maven clone :slightly_smiling_face: gradle is a zillion times better. and if _everyone_ was publishing native gradle concepts the world would be more gooder. Though i think gradle could do _a lot_  more to improve ergonomics for folks who need to rely on the fact that _maven exists_ and for the forseeable future the vast majority of people’s upstream dependencies are publishing only maven concepts (POM/BOM). even if the features are Opt-In (again, overriding maven properties is my biggest pet-peeve in this regard) it would go a long way methinks.

If one could live in a 100% gradle-native ecosystem, it would be awesome - but literally no one using any 3rd party dependencies can - so why not shave off the sharp edges for folks (everyone) who has a foot in both worlds. :slightly_smiling_face: /rant

For some things `compileOnly/compileOnlyApi` are exactly right, I'm huge fan of these configurations. I don't actually need gradle to define `providedCompile/providedRuntime` since I could easily create similar configurations it in a convention plugin.

But sometimes I need some deps to have `provided` scope in `pom.xml` for maven consumers and it was a bit of pain last time I did it.

from being the champion of catalogs at my org, i can tell you that people absolutely _hate_ working with (adding new entries) into the toml file. so we end up with various in-lined “string” dependency declarations containing... whatever version number folks pick (ugh!).  anything i can do short of manually copying every single entry from every bom we use into the catalog is a win for consistency.

I know it’s not exactly what you ask, but Build Scans present all failures in a nice way, including links to the relevant portion of the console log if needed. That could be a viable option for you?

`apply from` is the mechanism to invoke another script.

ok thanks, I’ll see if I can find some example f tht

following on from this I discovered that you can create a custom plugin quite easily and this is probably the best way, so I have copied <https://github.com/gradle/kotlin-dsl-samples/tree/master/samples/buildSrc-plugin> however my project is a multi-module project and I am getting `plugin was not found` errors

how are you applying the plugin in your subprojects?

normally I use apply because the plugin is declared in the root build file however I am trying to write the plugin within a subproject so I have added plugins:
```apply(plugin = "kotlin")
apply(plugin = "com.google.cloud.tools.jib")
plugins {
    id("greet")
}```

`Plugin [id: 'greet'] was not found in any of the following sources:`

using `plugins` is the correct way to reference it.  buildSrc should be at the root of the project to compile and expose that plugin.

ok that works thanks. if I want multiple plugins though, do they all have to be defined within `buildSrc`?

Yes, the plugins would go in buildSrc (or, alternately, in an includeded ‘build-logic’ project, but the effect is largely the same).  Typically you’d have a plugin for each convention - for example, a “java library” always has these settings (JVM version, javadoc settings, etc), and applying those conventions to relevant subprojects.

&gt; it could get a bit messy
If you already know that, don't do it.
I usually never use `buildSrc` nowadays, but always included builds.
And you can easily have one build you include per plugin you want to write or group a few in one build or however you like the buildtree to look like.

Context - the tests are running inside a docker container and I want to attach a debugger in my IDE (i.e. running on the host) using docker port forwarding.

This looks promising...
```tasks {
  test {
    if (project.hasProperty("debug-jvm")) {
      jvmArgs(project.property("debug-jvm"))
    }
  }
}```
Then run as so:
`gradle test '-Pdebug-jvm=-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005'`

Here is the according issue to be thumbs-uped: <https://github.com/gradle/gradle/issues/20644>

Hello, the fix for this issue is in progress! It's currently planned for 7.6.

```versionCatalogs {
    create("deps") {

        version("compileSdk", "32")
        version("minSdk", "23")
        version("targetSdk", "32")

        plugin("androidLibrary", "com.android.library").version("7.2")
        plugin("androidKotlin", "org.jetbrains.kotlin.android").version("1.6.21")

        version("vAndroidGradle", "7.2.1")
        library("kotlinGradle", "org.jetbrains.kotlin:kotlin-gradle-plugin:1.6.21")
        library("androidGradle", "com.android.tools.build", "gradle").versionRef("vAndroidGradle")
        library("androidGradleApi", "com.android.tools.build", "gradle-api").versionRef("vAndroidGradle")

        version("androidCore", "1.8.0")
        library("coreKtx", "androidx.core", "core-ktx").versionRef("androidCore")
        library("appCompat", "androidx.appcompat:appcompat:1.4.1")
        library("lifecycleRuntime", "androidx.lifecycle:lifecycle-runtime-ktx:2.4.1")
        bundle("androidCore", listOf("coreKtx"))

        version("vCompose", "1.2.0-beta03")
        library("composeRuntime", "androidx.compose.runtime", "runtime").versionRef("vCompose")
    }
}```


Questions:
1. Why am I getting this error?
2. Is there a specific relationship between `version()` and `bundle()` aliases, or are they separate? I would expect that the aliased libraries can all have different version values and that a bundle isn't restricted to having only a single version value per bundle.

odd error.  `listOf`should be resolve to stdlib - perhaps check the imports.  A bundle, by definition, uses a single version applied to each entry in the bundle.  that version can be different than versions used elsewhere.

hopefully that code is indeed Kotlin and not Groovy :wink:

apologies, my statement was incorrect (mind stuck on previous BOM / catalog discussion).  A bundle is simply a grouping of dependencies, using their versions as specified.

Thanks for #2, and I think I just face palmed number 1.

no worries, it all gets blurry sometimes…

Yep. It was a duh thing. I renamed every other script in the project to `.kts`... except `settings.gradle`.

Yes. As with other dependencies, Gradle can only handle one version of a certain plugin (usually it resolves to the highest).

If you define versions only through the *plugins block*, apply the other plugin there as well with a higher version

If you define the version though a dependency in *buildSrc / includedBuild*, add a *dependency constraint* for the other plugin’s coordinates with the higher version.

```invocation of Task.project📋 at execution time is unsupported. ?
⌄task:reader:jib📋 of type com.google.cloud.tools.jib.gradle.BuildImageTask📋
⌄exception stack trace 📋
org.gradle.api.InvalidUserCodeException: Invocation of 'Task.project' by task ':reader:jib' at execution time is unsupported.
	at org.gradle.configurationcache.initialization.DefaultConfigurationCacheProblemsListener.onTaskExecutionAccessProblem(ConfigurationCacheProblemsListener.kt:96)
	at org.gradle.configurationcache.initialization.DefaultConfigurationCacheProblemsListener.onProjectAccess(ConfigurationCacheProblemsListener.kt:59)

⌄⚠️cannot serialize object of type org.gradle.api.internal.project.DefaultProject📋, a subtype of org.gradle.api.Project📋, as these are not supported with the configuration cache. ?
›fieldproject📋 of com.google.cloud.tools.jib.gradle.ExtraDirectoriesParameters📋
›fieldproject📋 of com.google.cloud.tools.jib.gradle.ExtraDirectoryParametersSpec📋
›fieldproject📋 of com.google.cloud.tools.jib.gradle.OutputPathsParameters📋
›fieldproject📋 of com.google.cloud.tools.jib.gradle.skaffold.SkaffoldSyncParameters📋
›fieldproject📋 of com.google.cloud.tools.jib.gradle.skaffold.SkaffoldWatchParameters📋```


<#C013WEPGQF9|> might be a better place to get answers on this subject

<@UHATS9FCM> this topic should be located in google jib plugin

yes, I agree, I was merely asking for someone who knows the gradle API changes neccessary for configuration cache

Should I correct the code or is it configuration?

&gt; Task :compileTestJava FAILED
C:\Users\Miguel\IdeaProjects\<http://co.com|co.com>.choucair.certification.proyectobase\src\test\java\co\com\choucair\certification\proyectobase\runners\stepdefinitions\ChoucairAcademyStepDefinitions.java:25: error: illegal character: '\u00b3'
    public void heSearchForTheCourseRecursosAutomatizaciónBancolombiaOnTheChoucairAcademyPlatform() {
                                                         ^
C:\Users\Miguel\IdeaProjects\<http://co.com|co.com>.choucair.certification.proyectobase\src\test\java\co\com\choucair\certification\proyectobase\runners\stepdefinitions\ChoucairAcademyStepDefinitions.java:25: error: invalid method declaration; return type required
    public void heSearchForTheCourseRecursosAutomatizaciónBancolombiaOnTheChoucairAcademyPlatform() {
                                                          ^
C:\Users\Miguel\IdeaProjects\<http://co.com|co.com>.choucair.certification.proyectobase\src\test\java\co\com\choucair\certification\proyectobase\runners\stepdefinitions\ChoucairAcademyStepDefinitions.java:30: error: illegal character: '\u00b3'
    public void heFindsTheCourseCalledResourcesRecursosAutomatizaciónBancolombia() {
                                                                    ^
C:\Users\Miguel\IdeaProjects\<http://co.com|co.com>.choucair.certification.proyectobase\src\test\java\co\com\choucair\certification\proyectobase\runners\stepdefinitions\ChoucairAcademyStepDefinitions.java:30: error: invalid method declaration; return type required
    public void heFindsTheCourseCalledResourcesRecursosAutomatizaciónBancolombia() {
                                                                     ^
4 errors
&gt; Task :processTestResources UP-TO-DATE
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compileTestJava'.
&gt; Compilation failed; see the compiler error output for details.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at <https://help.gradle.org>
BUILD FAILED in 12s

It's the compilation errors that are in the output, likely from your code

Your problem is that you have a superscript three in your code (`\00b3`) where it is not allowed, or maybe you have an encoding problem like saving your file in UTF-8 but not telling the compiler and other tools about it and being on Java &lt;18.

I guess it is not a superscript three, but the `ó` in the method name combined with the encoding conflict I mentioned.

I'd figure out an appropriate encoding for your whole project and use it for all your project's module. then everything should be fine :smile:

Please do not split topics across several threads.
This makes following the conversation in the threads view very hard as the context of the other messages is missing.
If you have additional information either edit the original message or post to its thread.

Regarding the problem, you are not on latest version. 1.0.0-rc-2 is newer than the latest version, it is a release candidate. I guess that block was removed and the docs still describe the latest version. You probably should use the `maven-publish` means of doing it.

I'm very sorry about the split.

Anyway I just found out that there is <https://plugins.gradle.org/docs/publish-plugin-new|newer docs> for version +1.0. It's clearer to me now, thanks for your help.

Looks like this doc (<https://plugins.gradle.org/docs/publish-plugin>) is outdated. CC <@U02AWGJRHC5> in case you did not see this yet.

The best is to set version and group directly using `version =`  and `group =`  on the top level of the build script.
Do not set the `artifactId` . Make sure that the project is named the right was (_project name_ will be used as _aritfactId_).

Example of a full setup:
<https://github.com/jjohannes/extra-java-module-info/blob/main/build.gradle.kts>
Project name:
<https://github.com/jjohannes/extra-java-module-info/blob/main/settings.gradle.kts#L5>

This is also true for older versions of the “publishing plugin” if you apply “maven-publish” in addition.

Indeed version 1.0 will focus on a single way to setup plugin publication. The old documentation should have a clearer link to the new one until we get 1.0 out and reverse the relation :slightly_smiling_face:

This is something that I have been exploring a bit. Mostly the idea of publishing slack messages as a read only archive onto our <https://discuss.gradle.org/|forums> or even saving messages into a Gitter instance so they are more searchable. The slack search (in addition to the 10k limit) make it not the best platform for historical answers.

So does that mean this Slack does not qualify for free OSS plan, even though Kotlin Slack does (if that is correct information)?

What do you not like with the search? I found it quite useful and mighty unless limited by the 10K limit. I guess a copy of the messages would be better than nothing, but probably not as searchable, especially regarding metadata. Besides that it could be a privacy issue to do so. And DMs are also affected by the limit but wouldn't be covered by any external archive operation.

Since we also have an enterprise channel I don't think we qualify for the oss plan. I will see if we can find a way around that. For searching I really want regex… but I know that won't happen anytime soon. an or operator would be nice at minimum and better weighing of results would also help.

&gt; Since we also have an enterprise channel I don't think we qualify for the oss plan.
&gt; 
If that's the only reason, close it for the benefit of most users. :-D

I will look up the qualifications some more tomorrow 

I reached out to slack and they said we do not quality for even the discounted plan.

This may be of interest to make Slack searchable: <https://www.linen.dev/>

wow, never heard of it!  you found it or know of users?

it popped up on the Kotlin slack, they are trialing it.

<https://kotlinlang.slack.com/archives/C0922A726/p1655401266878639>

Stay tuned we are about ready for RC2. We had a week of company meetings in there so it might have been a little longer than normal.

<https://github.com/gradle/gradle/releases/tag/v7.5.0-RC2>

Just a side note, but I would almost always prefer a `Sync` task over a `Copy` task.

Regarding the actual question, it should be something like
```from(A) {
    into 'B'
}
into layout.buildDirectory.dir('X')```

I tried 100 things, but not that :slightly_smiling_face: Thanks a lot. Also, I didn't know about Sync. Will use it  from now on. Cheers!

This works for me, for v7.4.2: <https://services.gradle.org/distributions/gradle-7.4.2-bin.zip>.  The provided link is for a Very Old v 4.7.2, is that correct?

Oh damn it. Of course I meant 7.4.2 :grinning:

4.7.2 did not even exist, after 4.7 came 4.8 :slightly_smiling_face:

Yeah makes totally sense now. Sometimes brain and eyes do not work in harmony.

You've got `workingDir 'run'` set for the `test` task in `build.gradle` and the error is that `/home/runner/work/multiconnect/multiconnect/run` does not exist - is it possible you created it manually locally?

I'd guess just adding a `- run: mkdir run` to your steps before the gradle one will fix it.

Unless the error means that it can't find the `java` file...

the java is likely there (that’s the standard location for GitHub Actions installed JVMs) - the working directory is set to `…/run` which does not exist.

The missing run directory was the issue, thanks! I used to have a `run/.gitkeep` file but somewhere along the line it must have got deleted, I re-added it and it works now.

+1, I rarely search inside Gradle docs, I always go to Google to use it as search engine for Gradle docs, except when I am checking the javadoc, but here I get a search bar 

&gt; At least one can rely on CTRL+F to figure out information.
Unfortunately not. :disappointed:

The "single-sided" docs are just an excerpt. Most probably because they are just not wired correctly and no validation present, but noone cares to improve it it seems: <https://github.com/gradle/gradle/issues/16760>

And also <https://github.com/gradle/gradle/issues/15867> :-(

I wasn't aware that on version-specifc docs you have no search bar, but only on the "current" one. :-(

it's really a bummer to have so much doco and that no one can find them

Well, that's a bit overstated, as Google could find the right page, and you can use the "current" version with search bar, and the one-page version for most things with Ctrl+F. But there is definitely a significant improvement potential.

I know that information I'm looking for is available, I don't know where. Google doesn't help me, but often with the single page I can find it.

It is soooooooo frustrating to have to rely on Google indexing.

Same here, unless Ctrl+F refuses to find it, I struggle to find the correct search term and then at some point remember that it is just an excerpt and use the built-in search :smile:

plus I don't use google most of the time. Privacy matters, I use Qwant, but that's another issue :smile:

DuckDuckGo can find Gradle docs too without privacy issues. :wink:

Just search in the source tree with IntelliJ or `grep` =&gt; no privacy issues at all :smile:

I would like to point out
<https://boards.greenhouse.io/gradle/jobs/3694977>

Share if you want better docs and know someone that can deliver

It's not so much about the content <@U03AFQVC16K>.
It's about
single- and multi-page have different style,
single- and multi-page have different content,
search is only available with `.../current/...`, not even with `.../&lt;current version&gt;/...`,
...

:+1: and a few other things on the list for the TW once we have one. I agree the content is great!

Well, the doc writers we have at work would not be able to care about these points, at most complain and let some developer fix it. :-D

Another issue with search via google is that it prioritizes older page and sometimes when you try to switch to current you just get 404 since layout changed or some part of the docs was removed/merged

I'd say potential for another feature request to keep old links running by redirects to appropriate replacements.
Not sure how well that is possible though. :-D

It's common issue for a lot of projects and I haven't seen good solution yet ,(

Doesn't mean Gradle people couldn't come up with something :slightly_smiling_face:

&gt; +1, I rarely search inside Gradle docs, I always go to Google to use it as search engine for Gradle docs, except when I am checking the javadoc, but here I get a search bar
Fwiw, I never use Google to search the Gradle docs, I always go to <https://docs.gradle.org> and use the search box there. That being said, I rarely, if ever, use Google to search anything about Gradle; but I'm ready to admit I'm not a _lambda_ user.

Search engines can be instructed with metadata to prioritize the latest version. But, this requires rewriting of the old docs and knowing where they should point to now.

<@UAFGSU86M> I had the same surprise recently, the search box is only available on the `current` documentation. It has to do with the search framework not properly handling multi-version or something along those lines. I can see that both are confusing (searching older doc with the implicit hope of finding a newer concept/API vs not being able to see the search box on older version).

<@U03AFQVC16K> I think simply showing “you are on older doc, some features are disabled, please view latest doc at …” banner would go a long way.

We also have a documentation engineer that will start working at Gradle sometime before August.

Note that in my case it _was_ the latest, only referenced via an explicit number instead of `current`. But it doesn't change my mind: there should be a single page, searchable with CTRL+F.

look how distraction free are the Spring docs: <https://docs.spring.io/spring-data/jdbc/docs/current/reference/html/>

there's no need for a custom search box if you can simply find everything using ctrl+f. And even if you want one, it can be pure JS which searches in the doc.

I don't like custom control F tbh, prefer a search box 

the search box only exists because there's no way you can find anything in the docs today. I'm fine with a search box, but if the page is a single page, collapsed as in the spring docs, you don't need a dynamic search, you can have a static one.

I actually prefer both like it is now, just with the single-page doc fixed regarding the missing chapters and programmatically ensured all are there.
If I send someone a link, I usually prefer the search result from the search box instead of the single page result, as those single pages load faster and also sometimes browsers do not cleanly scroll to the given anchor.
So usually if I find the information I want to link to on the single-page Gradle docs, I search it there with Ctrl+F, then I search for it in the search box to get the split-docs link I want to share.

And besides that, the search box searches more than the docs iirc.
I think it also searches examples and maybe more.