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

Gradle Community

We always call them `testIntegration` to ensure that it both sorts together with `test` (and other things like `testFixtures`) everywhere and reads as command on the command line: `gradle testIntegration`

I usually call it `integTest` which is also the most widespread it have seen.

The Gradle docs on the other hand call them `intTest` here: <https://docs.gradle.org/current/userguide/userguide_single.html#sec:configuring_java_integration_tests|https://docs.gradle.org/current/userguide/userguide_single.html#sec:configuring_java_integration_tests>.
While that chapter should probably be changed to either use the JVM test suites plugin, or to use a different example.

<@U01A244DYUF> but your naming convention collides with Android and Kotlin multiplatform tests for example. I think integrationTest (or whatever in…Test) fits better because testFixtures are not tests themself

Probably, there's no standard so everyone does whatever. Not using Android nor multi platform so I don't know what they do.

There's no `testFixtures` task so that's fine.

Stuff like `int`, `intg`, ... is just cryptic. Not sure what's wrong with `integration`, `functional`, ... at least everyone understands what it is. Whether the test portion is the prefix or suffix shouldn't matter too much (except fs sorting) but it should be consistent. Having task names that resemble commands is imho always a nice too have.

&gt; at least everyone understands what it is
well, if only everyone had the same idea of what an “integration” test is : )

That’s a lost cause. :smile: We always only have `test` and `testIntegration` and that’s it.

I think this is what you're looking for: <https://docs.gradle.org/current/userguide/building_java_projects.html#sub:compile_deps_jvm_lang>

Unbenannt.txt

Can you try a build scan or running with --stacktrace to get more info?

Yes sure. What I currently figured out is when I put one of my other precompiled plugins into root level build.script like:
```plugins {
    id("de.myorg.configuration.project") version ("1.0.0")
}```
and remove the version from `id("de.myorg.configuration.android-app")` plugin in app build.gradle.kts it works. This makes absolutely no sense to me. I have 2 other precompiled plugins, both do not load any android related plugins and both work when I put them directly into plugins block with version in app build.gradle.kts. Only the precompiled plugins that load android plugins do not work...

What's on line 58 here? android-compose-application.gradle.kts:58 ?

<@UFDR8S97S> I do not have this line. I have currently changed the content of a`ndroid-compose-application.gradle.kts`  :
```package de.myorg.configuration

plugins {
    kotlin("jvm")
}

// Set a toolchain. This will update the toolchain for Kotlin and Java compile tasks as well
kotlin {
    jvmToolchain {
        (this as JavaToolchainSpec).languageVersion.set(JavaLanguageVersion.of(11))
    }
}```
It still does not work so it's not android plugin related or something which I assumed initially. This is really strange. Might this be a problem with the filename per se?

I'm not sure. I don't have access to all your files. I was just guessing. Check all the other lines that appear in the stacktrace for a clue

I have renamed the precompiled script and now gradle claims this plugin cannot be found even tho the file structure in the repo looks good. Meanwhile I think this fucking amazon s3 repo is broken somehow...

When I publish it to maven local everything works as expected. I will quit this fucking amazon s3 shit. Thanks for your time <@UFDR8S97S>

I recommend a build service (just search for it).

This looks like exactly what I need. Didn't know about such a feature. Thanks a lot!

actually, found;

```val collection: DomainObjectCollection&lt;MyClass&gt; = objects.domainObjectSet(MyClass::class)```

but I would still like to find a way to provide a custom “namer”

out of curiosity, why are you opposed to making a change to support this use-case?

I don’t want to couple `MyClass` to gradle API specific code. For the same effective reason extension functions are useful over instance functions

not to be difficult, but it's just unclear why you'd want a gradle-collection of something that wasn't already gradle-specific. Is `MyClass` also used for other build systems?

that said, I think you can just have a `name` property without implementing `Named`. So long as your class isn't `final`, Gradle will extend it at runtime

Tbh there’s no killer reason. Just want to have a clean separation of concerns. My new code to leverage `DomainNamedObjectCollection&lt;MyClass&gt;` is in one place - having to modify `MyClass` to support it is a bit messy

If you want such separation and class is not final you can just create subclass implementing `Named` and create named collection of these.

<https://youtrack.jetbrains.com/issue/KT-49798> there was a significant bug in Kotlin 1.6.0 that (combined with AGP 7.1.0) broke downstream consumers of Android libraries; is that what you're facing?

Hmm, no unfortunately I don’t think this is related to my issue. In my case the build succeeds, its just the actual content of the AAR file that is vastly different… it looks like whole code blocks are missing. So public functions that I used to call are no longer available

As an example, the same class. One is compiled using 7.0.4 (with implementation) and the other 7.1.1 (empty file)

Or is there a list of configurations that can be resolved during configuration? The various `compileClasspaths` are probably needed to determine task dependencies, so those should be ok, no?

`compileClasspath` and similar are usually resolved on execution when they are required for some compile task, same with code generation plugins if they are written correctly using lazy APIs.
If you just want to catch who resolves configurations before execution you can try execute some task like `help` with init script to delete all repos from `dependencyResolutionManagement` and `Project`s.

Another place to hook could be `ConfigurationInternal#beforeLocking` but I'm not sure when exactly it's fired and keep in mind that it's gradle internal interface so it's intrinsically unstable to depend on it

I don't need stable, this will probably be a one-off or at most occasional thing to look at, so I can try that, thanks. I don't understand how `help` would work, though, since configuration-avoidance prevents configuration of tasks that are not executed, so that's not good, no? Something like `assemble -m` might work, but that still won't tell me which task is causing the resolve, which is what I actually want to find out

You're right, `help` shouldn't trigger materialization of tasks in `TasksContainer` but could catch those which used eager api. And after that you could call `tasks.all { ... }` to materialize all tasks in configuration phase.
Idea with removing repos (and removing cache or pointing to empty gradle home dir) is to break on tasks which resolved configurations before execution phase.
I've never had issue similar to yours so suggestions above are just some ideas on possible approach

I'm not even sure we have issues there, tbh, but that's just what I want to find out. There seems to be quite a bit of work done in resolution during configuration phase according to the output, but it could be normal for a project of that size.

There could be legitimate reasons to do resolve in configuration phase (like configuring `pluginsManagement#plugins` or adding version catalogs) but most tasks shouldn't require it.
Good luck with identifying if there are such issues. I'd be interested to hear which approach works afterwards in case I have to do something similar in future.

Doing `gradlew build -m -i` on a clean cache dir looks promising, the log shows me for which task something is downloaded. Most of what I see there is ok, or at least probably unavoidable.

Thanks for the helpful discussion, this got me thinking in a new direction!

Not sure why it's doing that, but as a workaround you could put them in the `GRADLE_OPT*S*` environment variable

I had similar issue with linux tasks before and had to use text block without folding (`|` instead of `&gt;`) plus escaping newlines with `\` at the end of each line.
I'm a bit surprised that you run gradle with `run` step instead of `gradle-build-action` though

In Windows Powershell I needed to quote complex `-D` params, something like `-D"org.gradle.java.installations.auto-detect"=false`

Not entirely sure if that's this issue you're hitting here, though ;-)

<@UJUMPU407> gradle-build-action version <https://github.com/gradle/gradle-build-action/releases/tag/v2.1.0|v2.1.0> introduced the ability to configure Gradle with the action without requiring invocations to be managed by the action. This was my first test ...

Ahh, thanks. I'll look into that if it could be useful for my actions

I thought so too...  though, if I have to introduce windows-hacks such as `-D"key"=value`  or `|` instead of `&gt;` I'm not sure I'd want to move away from just letting the action handle the invocation.

afaik your best option for passing data between tasks is via output files or directories that gradle can track

<@U02FB7MB2JD>  workers with no isolation can spawn other work actions, but workers with other isolation modes can’t. See <https://github.com/gradle/gradle/blob/6134a82a9d34dea219fc01cfb330f28dd88aa199/subprojects/workers/src/integTest/groovy/org/gradle/workers/internal/WorkerExecutorNestingIntegrationTest.groovy#L106> and other test cases in that class

Using files is one way. You pass the path to outputs to your first action with classloader isolation, submit it, wait for it and then submit the other one passing the paths.

Depending on your use case you could instead use no isolation by passing the classpath as a parameter to your first action. Then you can spawn another from it.

<@UABCKNV3K> thanks, I'll use an intermediary file then to funnel the data to the second worker.
Is there a benefit from using property/lazy types in worker params or is it just convenience to connect them from the task properties more easily?

It is mostly good for convenience and uniformity. Worker parameters are realized before being passed to the worker anyway.

Do you think they should or they shouldn't?
And with what reasoning?

I thing they should. Otherwise both 1 and 2 point to the same API but have different explanation.
If I want to use the junitplatform only (without applying framework dependencies), then I have to call <https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html#org.gradle.api.tasks.testing.Test:useJUnitPlatform()>.
But the docs says I have to call different method.

Yes, both point to the same api and have different explanation, as they describe different aspects of this call.
Consider the sentence right in front of those two points:
&gt; Unlike the methods on the <https://docs.gradle.org/current/dsl/org.gradle.api.tasks.testing.Test.html|Test> task, <https://docs.gradle.org/current/dsl/org.gradle.api.plugins.jvm.JvmTestSuite.html|JvmTestSuite> methods perform two additional pieces of configuration:

Maybe my english is not good enough to understand the docs, but how could one method do two different things?

Another reading and I get it now. Thanks for your patience.

Because not all tests might need access to the code of the project or the dependencies of the project.
See <https://discuss.gradle.org/t/7-3-test-suite-inherit-test-libraries-for-integration-test/41980/4> for more information from core developers and ways to remediate.

I didn't find this topis. Thanks for pointing it out.

obviously this spits in the face of project isolation, but I do need this and I’d like to find a way to idiomatically do this in the best way

note: `ModuleConfig` is simply a `data class` that has some properties that describe a subproject. For example, it has an `hasAndroidTests: Boolean` that is used to configure whether a subproject…has android tests. And if it does, additional tasks are configured. It also allows us to create groupings of related modules (multiple subprojects that are a part of the same feature) and then run android UI tests on just that group/feature

we also have a `ModuleConfig#isPublished` boolean so we can create a root task like `./gradlew publishAssembleDebug` (assemble the debug variant of everything we publish)

I’m currently using a statically defined list in `buildSrc` - `val Modules.ALL: List&lt;ModuleConfig&gt;`. I want to move away from this globally defined list, and allow each subproject to register its `ModuleConfig` itself in its own `subproject/build.gradle.kts` script.

My thought process is that instead of a `List&lt;ModuleConfig&gt;`, create a plugin that loops over all subprojects and generates a `DomainObjectCollection&lt;ModuleConfig&gt;` and then allow consumers to observe it

I have no idea but there are docs about how to collect jacoco docs but because each project add them instead of doing allprojects { … }. Looks similar to what you want to achieve 

any chance you could link to the docs you’re referring to?

I looked for it but I am finding the new docs released with 7.4 I think, I can't find the older

You probably mean <https://docs.gradle.org/current/userguide/cross_project_publications.html>

I need to depend on all projects that implement a specific plugin. it’s an aggregation use case

That chapter also is about aggregation of information from other projects.
It is what the test-report-aggregation and jacoco-report-aggregation plugins are based on.
And before those plugins were there, only that chapter described how to aggregate the JaCoCo result files.
That's why I think Javi meant it.
Whether it solves your problem, I don't know.

yeah it is, I have misunderstood your issue

I have the same problem interestingly enough so would be interested in what it might be as well.

Hello <@USNE4GL0G> - Can you check this out <https://jfrog.com/knowledge-base/artifactory-deploying-and-resolving-different-artifact-types-through-a-gradle-job/>. This seems to have worked for me. Though need to do a bit more testing.

There is some info in this thread where I got BuildService working: <https://gradle-community.slack.com/archives/CAHSN3LDN/p1643763774027789>  (more than halfway down that thread) in case it helps you a bit.

I'm not sure exactly what your trying to do but I setup a bunch of junit test stuff in a plugin a wrote so all my projects just need to include the plugin and then get things like maxParallelForks set, jacoco set, tags set, junitPlatform set, etc.  So my approach was different (i.e. using the apply of plugin to set it all up)

The build service actually does the job. My problem is, that calling `maxParallelUsages.set(Provider&lt;&gt;)` with a `Property&lt;&gt;` actually doesn't work as I expected. Even though the `Property&lt;&gt;` changes its value via build script, the service always uses its _initial_ value.

Looks like a current limitation of `registerIfAbsent`:
<https://github.com/gradle/gradle/blob/e27ff70a01ca1e7d73be00e17a8f89a6b5ece27b/subprojects/core/src/main/java/org/gradle/api/services/internal/DefaultBuildServicesRegistry.java#L119|https://github.com/gradle/gradle/blob/e27ff70a01ca1e7d73be00e17a8f89a6b5ece27b/sub[…]/gradle/api/services/internal/DefaultBuildServicesRegistry.java>

Why do you think the eager execution of the configuration action is the problem? That should still just associate the two properties, shouldn't it?

<@URQ797WRW>Well, the Build Service guide:
<https://docs.gradle.org/current/userguide/build_services.html>
_To create a build service, you register the service instance using the <https://docs.gradle.org/current/javadoc/org/gradle/api/services/BuildServiceRegistry.html#registerIfAbsent-java.lang.String-java.lang.Class-org.gradle.api.Action-|BuildServiceRegistry.registerIfAbsent()> method. Registering the service does not create the service instance. This happens on demand when a task first uses the service. If no task uses the service during a build, the service instance will not be created._
And from the Lazy configuration guide:
<https://docs.gradle.org/current/userguide/lazy_configuration.html>
_Gradle provides lazy properties, which delay the calculation of a property’s value until it’s actually required._

I simply assumed that if the configuration action binds two properties, that once the property is actually needed that it will load it from actual value. If the action is evaluated eagerly, why it uses `Provider&lt;&gt;` type for the property? Provider type indicates lazy evaluation to me.

It looks like that <@UDC9Q9RD0> hit the nail on the head.
Thank you.

So my only way to overcome this would be some sort of a _configuration task_ which will be executed prior to the test task itself and which will set up the service in its _action_ section.

My question was directed to <@UDC9Q9RD0>.
I didn't read your whole code, but I don't think the linked comment is the culprit.
Just executing this configure action eagerly just means the association between the two properties is eagerly done, not that the value is eagerly calculated.

&gt;  Just executing this configure action eagerly just means the association between the two properties is eagerly done, not that the value is eagerly calculated.
Yop, that is correct. But during the execution phase, `maxParallelUsages` has the initial value of the `maxParallel` property. So it doesn't evaluate lazily as I would expect.

<@URQ797WRW>, look 4 lines below (line 123) :wink:
(this is related to the comment in that if the action execution was deferred then evaluation of the property would also be deferred; I link to the comment to emphasize the "current limitation" that could be lifted in a future version, rather than a "by design" decision)

Javadoc says it could be `project.state.executed`

Sounds like you shouldn't actually do it. :smile:
What's the use-case?

I had to do some weird logic here around `plugins.withType` and `plugins.whenObjectAdded`

```rootProject.allprojects {
    // this if/else loop is to workaround some weird gradle lifecycle issues
    // we have verify tasks that ensure this does not cause any problems though
    if (plugins.hasPlugin(ConfigPlugin::class.java)) {
        plugins.withType&lt;ConfigPlugin&gt; {
            action.invoke(
                the&lt;Config_gradle.ModuleConfigPluginExtension&gt;().module.get()
            )
        }
    } else {
        plugins.whenObjectAdded {
            val plugin = this
            if (plugin is ConfigPlugin) {
                afterEvaluate {
                    the&lt;Config_gradle.ModuleConfigPluginExtension&gt;().module.get()
                }
            }
        }
    }
}```
Was getting some weird error around calling `afterEvaluate` if I used `plugins.withType` in the second `else` block.

I think `withType` leverages `afterEvaluate { }` internally? If that is the case then I could leverage it only instead of `plugins.whenObjectAdded`, I just wasn’t sure

No, `withType` should not call `afterEvaluate`.
And your construct does not make much sense to me.
You ask whether the plugin is applied already and if so, you use the reactive method that works whether the plugin is applied already or not and if it is not applied already you use `whenObjectAdded` and an `afterEvaluate`.
This does feel very wrong.
Just having the content of the `if` should cover the same cases and be cleaner.

Still dirty though, because the JavaDoc of  `project.plugins` tells you not to use it.
You should instead use `pluginManager.withPlugin`.

that’s probably why I couldn’t find the right API

Also look at `./gradlew help --tasks myRunTask`

A build scan will answer that for you, but it most likely happens because `A:jar` runs after `A:test` and is required by `B:test`

We are looking into changing that in Gradle 7.5 by saying that `test` `shouldRunAfter` `jar`.

aha brill thank you, yes excluding the jar task allows them to run in parallel

Just make sure you execute the `jar` task separately in a Gradle run before then. Or `B:test` is pretty meaningless if it works with an outdated JAR, or can even fail if the JAR is not present and due to the exclusion also is not created.

~<https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:meta_inf_normalization>~
~Could help as well.~

To handle 'up-to-date' checks for `jar`s.

But that is absolutely not helpful.
1. you linked the meta inf normalization which does not apply at all here
2. even if you consider the chapter before, it is about runtime classpath normalization. so it does not influence the up-to-date check of the `jar` task,
       it influences the normalization of runtime classpath inputs of tasks using the result of the `jar` task, so that for example a `test` task does not need to run again just because the version in a properties file changed that is not relevant for testing and similar things
3. and even if it would influence the `jar` task up-to-date check - which it does not -, the `B:test` task would still need to wait until the `jar` task finished to see that it is up-to-date.

probably R8 can see (correctly) that none of the classes are being used, so it removes all of them?

You might consider updating the proguard rules file to specify an entry point to "keep" in your library. Then everything referenced by that, transitively, will not be removed

If you run any task from the main build, they are run automatically. If you mean targetedly, then not from the main project directly as long as it is still not a standard included build. If you switch to included build instead of `buildSrc`, it just works. Like it is you can leverage the `-p buildSrc` option to invoke the `buildSrc` build separately, or `cd` into `buildSrc` and use `../gradlew`.

could you explain `-p buildSrc` some more?

``` ./gradlew -p buildSrc :build```
is exactly what I needed. Thank you!

&gt; could you explain `-p buildSrc` some more?
As I said, practically the same as `cd buildSrc; ../gradlew build; cd ..`

AFAICT this is supposed to happen already: see this call to `attachProducer`?
<https://github.com/gradle/gradle/blob/bb1ef4eeb041a7487ac946e79f994b51ecf5aaca/subprojects/core/src/main/java/org/gradle/api/internal/tasks/DefaultTaskOutputs.java#L163|https://github.com/gradle/gradle/blob/bb1ef4eeb041a7487ac946e79f994b51ecf5aaca/sub[…]main/java/org/gradle/api/internal/tasks/DefaultTaskOutputs.java>

Whoops, got used to using the special DSL sauce that allows assignments to properties. Replacing `outDir=...` and `inDir=...` with `outDir.set(...)` and `inDir.set(...)` works.

Thanks for pointing out the implementation <@UDC9Q9RD0>

For anyone that comes across this later; beware, the `attachProducer` method used in Gradle only works on `Property`s, it does not work with `Provider`s.

Welcome to Gradle classloaders ! I'd recommend reading <https://dev.to/autonomousapps/a-crash-course-in-classpaths-build-l08|https://dev.to/autonomousapps/a-crash-course-in-classpaths-build-l08> if you haven't already. 

Overall, my understanding is that the classpath isn't shared but more that the root classloader comes before the subproject one. So it's still 2 different classpaths. Only conflict resolution doesn't happen as you would expect

I see, so shouldn't the root project classpath dependencies override the subproject dependencies in the lockfiles (as they do in the resolution eventually)?

Not in the lockfile.
There is no conflict resolution and no overriding of the version.
The subproject buildscript class path has its own version.
But the superproject class loader that contains the superproject class path is the parent class loader of the subproject class loader containing the subproject class path.
And according to Java class loading rules, the parent class loader is asked for a class first and used if it has the class.

are you asking if you can mix and match managed and unmanaged?

No… I understand this is impossible… I’m wondering if there is some crafty solution that can avoid the managed property…

oh, I didn't know that was impossible. I was sort of hoping you could leave certain properties abstract so gradle would manage them, and the ones you want more control over, remove the abstract modifier

at least I thought so… except now I can’t find the appropriate documentation reference.

try it? Leave some properties abstract, inject an object factory, and see what you can do...

yeah… I think it works. I think I was getting confused by some other issues with generating the decorator for that type

(there are no stupid questions… only stupid people)

Sounds like it should work.
Can you provide an MCVE?

So since it made sense to you, I went back recreated my setup on the same project.. and it started working.  Not sure what it was in the end unfortunately.

you should probably be using <https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html> instead of custom configurations for setting up `smokeTest`

but basically it's the Java plugin that's setting up each Java `sourceSet` to have a `implementation`, `api`, etc. configuration, using those for the Java compilation

&gt; *Can something useful be done with custom configurations without Ant?*
Yes. It has nothing to do with Ant actually…

If you  want to understand the concept better (shameless plug): <https://www.youtube.com/watch?v=igug9tbl4J4&amp;list=PLWQK2ZdV4Yl2k2OmC_gsjDpdIBTN0qqkE&amp;t=0s>

You can jump to min 8, where I start talking about the “Configuration” concept.

Basically, when you have a custom configuration like “smokeTest” you need some place where you use (i.e. _resolve_) it. Usually you set it as an input to a task. The task will then treat it as a “collection of files” and as soon as Gradle gets to the point where the task needs the files, it will “resolve” the dependencies (interprete the metadata / download the Jars).

In your example, you would probably set “smokeTest” as the `classpath` of a `Test` Task.

I was busy otherwise, but thank you both for the helpful feedback.
Jendrik Johannes' videos are great! They clarified a lot of things for me and will help me improve our build scripts.

I tried that but dependencies always shows up empty.  I tried a bunch of of variations but not luck.  Maybe I'm missing where they are contained in buildscript?

You usually get dependencies from configurations. `dependencies` is where you declare them.

I tried the following but the dependencies are always empty
```register("bbb") {
        project.buildscript.configurations.forEach {
            println("Bellini: configurations")
            println(it.name)
            println("Bellini: deps")
            val deps = it.dependencies
//            deps.iterator().forEach {
//                println(it.name)
//            }
            it.allDependencies.iterator().forEach {
                println(it.name)
            }
        }
    }```


Output is
```Bellini: configurations
classpath
Bellini: deps```


Maybe because you do it at configuration time instead of execution time? (missing `doLast`)

Tried with doLast{} but still empty unfortunately.

Works fine here, even at configuration time

Maybe you don't have dependencies in that build script class path

Thanks for helping here.  Here is what my  `buildSrc/build.gradle.kts` looks like:

```plugins {
    `kotlin-dsl`
}

repositories {
    mavenLocal()
    mavenCentral()
    gradlePluginPortal()
}

dependencies {
    val versionKotlin = "1.5.10"        // help with version upgrades to make sure all version are aligned in this file
    implementation("org.jetbrains.kotlin:kotlin-allopen:$versionKotlin")

    implementation("com.ea.stuff:stuff-common:16.6.0-SNAPSHOT")    implementation("org.kie:kie-api:7.45.0.Final")
    implementation("org.drools:drools-compiler:7.45.0.Final")
    implementation("com.fasterxml.jackson.core:jackson-databind:2.13.1")
}```
What I want to programmatically obtain is the version of the dependency `com.ea.stuff:stuff-common:16.6.0-SNAPSHOT`

That is not a buildscript dependency, but a normal project dependency

Only not-built-in plugins from the `plugins` block and things from a `buildscript { dependencies { ... } }` block are buildscript dependencies

Interesting... even though its the `buildSrc/build.gradle.kts` dependencies which has the plugins listed + and code used in the build script?

And where do you have the `bbb` task?
And actually, what do you want to achieve?

I want to programmatically obtain is the version of the dependency `com.ea.stuff:stuff-common:16.6.0-SNAPSHOT` from the `buildSrc/build.gradle.kts`dependencies section.

The `bbb` task is in a `stuff-conventions.gradle.kts` file with in the `buildSrc/src/main/kotlin/.../stuff-conventions.gradle.kts`

Actually your problem is that you are using `buildSrc` and not an build.
plugins / dependencies from an included build end up on the buildscript class path.
(while you would still miss the dependency, because with your code you only get declared dependencies, no transitive ones which that one is from the viewpoint of the main build)
`buildSrc` dependencies are in its own class loader that is a parent of the build script class loader.
So those dependencies are not part of the build script configurations you are looking at.

What do you want to access the version for?
I suspect that "I want to get the version of that dep" is your try to solve the actual use-case, but is not the use-case itself.

I need to pass that version to a subprocess that is the gradle build starts but doesn't control.  So rather than hard coding the version in two places, I want to programmatically grab it.

If you want to get the version at runtime, you probably need to get a class from that dependency and then get that classes codesource from its protection domain and then parse the version out of the JAR file name.
Or if that dependeny provides its version via some Version class or properties file or manifest entry, then you might get it from there.
Or you get the version not in your convention plugin, but actually during the buildSrc build and write it to some properties file your convention plugin then can read.
Or you define the version in some variable (or probably better in a version catalog) and then use it to declare the dependency and also to generate said properties file with a `WriteProperties` task, or with a filter on `processResources` to fill in a blank in a properties file you create manually, that your convention plugin then can read at runtime.

Thanks.  I tried adding it to gradle.properties and then reading the properties but the `buildsrc/build.gradle.kts`doesn't have access to that.  Version catalog would be good to try assuming `buildsrc/build.gradle.kts` can access it (haven't tried).  Appreciate the ideas, I'll work through some of these and see what works.

&gt; tried adding it to gradle.properties and then reading the properties but the `buildsrc/build.gradle.kts`doesn't have access to that
`buildSrc/gradle.properties` I hope.
Otherwise it would make little sense.
Well, you could even read `gradle.properties`, but you then have to do it explicitly, using a `Properties` instance.

There is not even a "Gradle" way to have a project-temporary directory, only the task-temporary directories, which are not actually temporary directories either, as they are not cleared up ever except if you do it yourself.

I was told by Gradle guys to just use the normal Java facilities to create temporary directories.

Which is what I have done… so now I know thats the recommended approach. Thanks

The docs don't seem to address this, or I can't find where/if it's addressed.

i use this <https://github.com/radarsh/gradle-test-logger-plugin>

I'll check it out. It looks like it should work `showFailedStandardStreams true` is a option. hopeful.

all the output gets stashed in build/test-results/* by default

same format as Ant, as <https://docs.gradle.org/current/userguide/java_testing.html> says. that format is described at <https://ant.apache.org/manual/Tasks/junitreport.html>

that looks like it's just a report of which tests passed or failed.

I want the stdout/stderr of the test that failed.

also, it doesn't seem to generate the xml report for failed tests either.

it does capture stdout/stderr and failed tests in my projects, I'm not sure what would make that not work

I also have jacoc code coverage plugin. likely some interaction.

build_test-results_test_TEST-ExampleTest_xml.xml

e.g. this trivial test produces this output
```import kotlin.test.Test

class ExampleTest {
    @Test
    fun test() {
        println("hello")
        System.err.println("world")
        throw RuntimeException()
    }
}```
whether jacoco is on or off. so perhaps it's an issue with your test framework or some other configuration

could be. I have a mix of standard junit tests and cucumber tests.

actually, I take that back. intellij is generating xml files. grade is generating nothing.

yeah. 100% gradle is not creating test reports of any kind. What's the magic to to this on?

it is generating a `output.bin` in the test-report directory. But there doesn't seem to be much documentation on what this is, or how to use it.

oh well... I guess I need to reverse engineer this format so I can get the stdout for my failing test?

I guess I'm up for another day of faffing with gradle, instead of doing what I'm actually paid to do.

I'm never using gradle on another project again.

Unless you deactivated it, Gradle creates a nice html report for the tests where you can also see stdout / stderr. This works for me for all projects in had so far.

Gradle imho is the non-plus-ultra when it comes to build tools. But to everyone his favorite tool. If you don't like, don't use it.

here are some settings i use that could be useful to you:

```tasks {
    withType&lt;Test&gt;() {
        maxParallelForks = Runtime.getRuntime().availableProcessors()
        useJUnitPlatform()
        testLogging {
            setExceptionFormat("full")
            setEvents(listOf("passed", "skipped", "failed", "standardOut", "standardError"))
        }
    }
}
configure&lt;com.adarshr.gradle.testlogger.TestLoggerExtension&gt; {
    theme = com.adarshr.gradle.testlogger.theme.ThemeType.STANDARD
    showCauses = true
    slowThreshold = 1000
    showSummary = true
    showStandardStreams = true
}```

<@U0381HHT672> Those settings will spit out stdout/stderr for every test. Also, since the failure is a timeout, and the tests are running in parallel (as you have set), it's pretty much useless. The error has exceeded the scrollback buffer in the terminal.

<@URQ797WRW> yes, that's what the docs imply. "It should just work". Except that it doesn't... and AFAICT there is no way to figure it out besides just randomly turning on/off plugins until the culprit is found.

And then dig around in that plugin to see why it's preventing test-reports to run. And it's likely written in a language I don't give a crap about...

This has been my experience w/ gradle. Works like magic... until it doesn't. Then it's impenetrable

You confuse that with Maven actually, which is a big black uninvestigatable black box where you are absolutely lost if anything strange happens.

If you blindly apply dubious plugins from which you don't know what they do, they can of course have unexpected effects. But that is not the fault of Gradle. I know what the plugins do that I apply and my builds do exactly what I expect. It's the same in any other build tool. If you use strange plugins, that do strange things, things might go unexpected and it is not the tools fault. 

But as I said, if your personal experience is different from most of your fellow developers, just don't use the tool, but use one that suites you better. :-)

what makes you think the plugins I'm using are dubious, or that I don't know how they work?

Have you ever worked on a modern large project with automated CI? There are LOTS of plugins. artifactory, sonic qube, jenkins, jacoco... the list goes on. Do you go and read all the source code for all of those? of course you don't

you have a polygot repro, maybe using cucumber as well? You want to tell me with a straight face you understand exactly how all those plugins interact with each other? Of course you don't..

If you need to disparage me rather than taking a critical look at the tools you use... I think that says more about you than me.

That’s some serious negative energy to use in a community support channel. Not sure what you’re trying to achieve with that.

I'm sorry if you felt offended, is was neither my intention to do so, nor to disparage you.
It were just objective obeservations.
&gt; what makes you think the plugins I'm using are dubious
I said "dubious" because if a plugin magically unexpectedly disables both, the JUnit XML report and the HTML report on the test task, which by default are enabled, so that you can see the output you are missing, that's what I call dubious unless the plugin is specifically meant to do that.
&gt; or that I don't know how they work?
I said "you don't know how they work" because that is what you said yourself. You said you need to disable plugin by plugin to find out which disables the reports that are on by default, which implies you don't know what they do or you would know which plugin is the culprit and that it is not Gradles fault.
&gt; Have you ever worked on a modern large project with automated CI?
Yes, I do that on a daily basis
&gt; There are LOTS of plugins. artifactory, sonic qube, jenkins, jacoco... the list goes on. Do you go and read all the source code for all of those? of course you don't
&gt; You want to tell me with a straight face you understand exactly how all those plugins interact with each other? Of course you don't..
Of course I don't know all plugins I use inside-out codewise, but I know what they are supposed to do and whether they are supposed to disable absolutely useful reports or not.
And I actually am not aware of any standard or common plugin that does that, as it does not really make much sense imho, which again comes down to the "dubious" part if it is some plugin that disables it.
If a plugin is not "dubious" and disables such important reports, I expect it to have that in its documentation crystal clear or otherwise it is dubious.

Actually indeed I know how many of the plugins I use do work internally, as I often want to know how they work or what they do to evaluate whether I want that in my builds or not.
But very interesting that you seem to know exactly what I do or don't do. o_O

Maybe you need to depend on the artifact generated on the taskA of all the projects, and not the tasks.

There is no dependency between the tasks.

I would start reading this: <https://docs.gradle.org/current/userguide/declaring_dependencies_between_subprojects.html#sec:depending_on_output_of_another_project|https://docs.gradle.org/current/userguide/declaring_dependencies_between_subprojects.html#sec:depending_on_output_of_another_project>

I simply want any `taskB` to start its execution after all `taskA` are done. No dependency between them. Just simple task ordering.

Well, it is less a matter of scope. It is simply if you reference `taskA` in a project then you reference exactly that projects `taskA`. So if you do `taskB.mustRunAfter(taskA)` , yes it of course only affects that projects `taskA`.

You probably need something like `taskB.mustRunAfter(allprojects*.tasks*.withType(TaskAType))` or similar. Hard to say concretely with that little information.

The reason of my doubts was one sentence from: <https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:ordering_tasks|https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:ordering_tasks>
describing a difference between `mustRunAfter` and `shouldRunAfter` talking about _parallel execution._ And I immediately applied those two words to multi project parallelization (because there is no default task parallelization in single project setup as far as I know). 
Thank you for the clarification. 

In my setup, both `taskA` and `taskB` have the very same type. They differ in inputs only. They are generated according to the user configuration. So I can distinguish them by names only. 
The solution with `gradle.projectsEvaluated` I posted above works for my use case. 

&gt; The reason of my doubts was one sentence from: <https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:ordering_tasks>
&gt; describing a difference between `mustRunAfter` and `shouldRunAfter` talking about _parallel execution._ And I immediately applied those two words to multi project parallelization (because there is no default task parallelization in single project setup as far as I know).
Not sure what parallelization and difference between `mustRunAfter` and `shouldRunAfter` have to do with your question.
Actually there is also task parallelization in single project depending on conditions.
For example if you use configuration cache, tasks run in parallel, that's one of the reasons for it.
Or if you have tasks using the worker api at least the work items can run while another indpendent task starts in parallel already even without configuration cache.
So `mustRunAfter` enforces order even if things could be done in parallel, `shouldRunAfter` not.

&gt; In my setup, both `taskA` and `taskB` have the very same type. They differ in inputs only. They are generated according to the user configuration. So I can distinguish them by names only.
&gt; The solution with `gradle.projectsEvaluated` I posted above works for my use case. 
Then maybe something like `taskB.mustRunAfter(allprojects*.tasks*.withType(TaskAType)*.matching { it.name == 'taskA' })` (just do not use `matching` without `withType` or you force realization of each and every task, making task configuration avoidance void).
If you use `projectsEvaluated` and it is ok for your use-case it might be ok.
But you might miss tasks added in a later hook then if that might be an issue.

I opted for the Regex foo, thank $deity we enforced some stylistic rules on the build files so this wasn't a nightmare. :upside_down_face:

i've used <https://github.com/littlerobots/version-catalog-update-plugin> to create initial ones