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

Gradle Community

Where do you "not see" it?
Can you provide an MCVE that shows your issue?

I'm just looking under the verification section in the Tasks lists in the gradle view in AS.  I don't have a MCVE atm, but I can try to get one set up

Did you try to reload the project after doing the change?
Do you see it in the output of `tasks` task?

if i try to run the jacocoTestReport task, it will fail since it can't find it

Ok, then an MCVE would definitely help.
Either you to see your problem while creating or others to spot your problem

ok, i think this is somewhat close to what I'm working with: <https://github.com/fluxxion82/TestReport>
I'm not seeing the reportTestReport task when i apply the plugin in the subprojects block, which isn't what I see in my other project. I have some plugin/task configs in my other project but just trying to figure out where the task is. I also expect to see a jacoco folder show up in the build folder with the exec file, but not seeing that either

Hm, maybe the Android plugin doing strange things and not being compatible with the built-in JaCoCo plugin?

any ideas on how to check? maybe it's gradle plugin? on my main project, i saw the jacoco folder  and the tasks show up at some point, but not sure what conditions...i was changing the scripts around a bit before i noticed

I'm not doing Android.
Maybe you had non-android projects and had seen the task there or something?

Other than that, set a breakpoint in the JaCoCo plugin class and debug the build

This one is fun with AGP.
I’ve always had to register the task. As of AGP 7.3, you’ll want to use the onVariants API to say that unit test is finalized by generating jacoco test report + generating jacoco test report depends on unit test. e.g
```androidComponents {
  onVariants(selector().all(), { variant -&gt;
    afterEvaluate {
      tasks.named("test${variant.getName().capitalize()}UnitTest").configure( {
        it.finalizedBy(project.tasks.named("generate${variant.getName().capitalize()}JacocoTestReports"))
      })
      tasks.named("generate${variant.getName().capitalize()}JacocoTestReports").configure( {
        it.mustRunAfter(project.tasks.named("test${variant.getName().capitalize()}UnitTest"))
        it.dependsOn(project.tasks.named("test${variant.getName().capitalize()}UnitTest"))
      })
    }
  })
}```

You’ll want to configure the actual task for generating test coverage reports, this will just ensure that it gets added and executed properly.

so i've registered a task, which I see shows up under the Other section in the gradle task list in AS, but I don't see the jacocoTestReport task, which i guess is ok since my task is a jacoco report task. however, i don't see reports in my modules, except for two of them, which I think is because they don't use any android plugins really.
I've been trying to do most of my configurations at the root level, although I've also been trying at the app level as well and combination of root level and app level.
i see my other modules getting configured when i build gradle and run the tasks, but don't see any reports, except in two non android modules

How are you registering it? With build types and flavors, you'll want to define them

i've tried doing it per variant. something like
```tasks.register&lt;JacocoReport&gt;("${variant.name}CodeCoverageReport") {
                val kotlinDirectories = fileTree(
                    "${project.buildDir}/tmp/kotlin-classes/${variant.name}"
                ) { exclude(excludedFiles) }

                val coverageSrcDirectories = listOf(
                    "src/main/java",
                    "src/debug/java",
                    "src/us/java"
                )

                classDirectories.setFrom(files(kotlinDirectories))
                additionalClassDirs.setFrom(files(coverageSrcDirectories))
                sourceDirectories.setFrom(files(coverageSrcDirectories))
                executionData.setFrom(
                    files("${project.buildDir}/jacoco/test$${variant.name}UnitTest.exec")
                )
            }```

that block in in the
```androidComponents {
    onVariants { variant -&gt;
    }
}```
block

also, can’t remember if it changes with gradle or AGP, but it’s output is to `build/outputs/unit_test_code_coverage/`   - <https://issuetracker.google.com/issues/195860510>

missed this on my end, <https://developer.android.com/reference/tools/gradle-api/7.3/com/android/build/api/dsl/BuildType#enableUnitTestCoverage()>. Perhaps just means you need to configure the tasks for the project and enable on the build type. Honestly, hadn’t noticed that addition until now.

Found this as a result - <https://medium.com/@gmazzo65/generating-android-jvm-aggregated-coverage-reports-53e912b2e63c>

so I see the jacoco folder showing up in a bunch of my modules again, but the folder is empty. I updated to agp 7.3, set `enableUnitTestCoverage`  to true, registering a task with each variant, but no reports or exec files. don't see any outputs at the root of the project either, despite people saying that in the issue you linked. maybe there's something with my task configs :thinking_face:

Were you able to resolve the JaCoCo related issues?

actually no..ran out of time to get things sorted but going to be picking things up again soon.

I'm not sure what you mean.
If you have them as `RegularFileProperty`, then you use `set(...)` or `convention(...)` depending on intended result just like for any other property.

I would never have thought to use `RegularFileProperty`

lol, why? didn't see it in the documentation :wink:

Then read the documentation again. :wink:

```03:09pm] ./gradlew --version

------------------------------------------------------------
Gradle 7.5.1
------------------------------------------------------------

Build time:   2022-08-05 21:17:56 UTC
Revision:     d1daa0cbf1a0103000b71484e1dbfe096e095918

Kotlin:       1.6.21
Groovy:       3.0.10
Ant:          Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM:          17.0.4.1 (Eclipse Adoptium 17.0.4.1+1)
OS:           Mac OS X 12.6 x86_64```

In case it helps anyone in the future: that’s the behavior if you don’t load the `groovy` plugin.  :blush:

I may PR a warning message for the plugin.

You cannot really emit a warning cleanly, because you cannot reason about the absence of a plugin without dirty tricks.

But as CodeNarc only makes sense with Groovy, it might maybe be appropriate to apply the groovy plugin instead of reacting to its application.

“…without dirty tricks…” :smiling_imp:

Oh… yeah… I suppose it would be sane as a transitive dependency.  D’you know if there are others in… wait… yes… `war` loads other plugins, yeah?

Most internal plugins probably apply others and be it just the `base` plugin.

`application` applies `java` and `distribution`
`java` applies `java-base`
`java-base` applies `base`
.....

Using this pattern:
```public fun &lt;T&gt; ProviderFactory.conditionalListOf(predicate: Provider&lt;Boolean&gt;, vararg elements: T): Provider&lt;List&lt;T&gt;&gt; {
    return predicate.orElse(false).map {
        if (it) {
            elements.toList()
        } else {
            emptyList()
        }
    }
}```
```        named(BUILD_TASK_NAME) {
            dependsOn(providers.conditionalListOf(providers.ciBuild().negate(), spotlessApply))
        }```

is it `dependsOn` you are after?  If not this may be applicable:
```public inline fun &lt;reified S&gt; Provider&lt;S&gt;.filter(crossinline predicate: (S) -&gt; Boolean): Provider&lt;S&gt; {
    return flatMap {
        if (predicate(it)) {
            Providers.of(it)
        } else {
            Providers.notDefined()
        }
    }
}```
…returns an empty provider is the condition is not met.

Having not tried it yet I am trying to understand how those would tell the task not to do anything. Or perhaps tell the task that is already up to date. Basically I just need the exec command not to run if in CI

If it is in CI it should basically be up to date. as that command has run before commit

ok, so not dependsOn but onlyIf.
```public fun Task.onlyIf(spec: Provider&lt;Boolean&gt;) {
    onlyIf { spec.getOrElse(false) }
}```
```onlyIf {
                when {
                    isCIBuild() -&gt; when {
                        isSnapshotVersion() -&gt; repository.isSnapshotRepo()
                        else -&gt; repository.isReleaseRepo()
                    }

                    else -&gt; repository.isLocalRepo()
                }
            }```

pulled from my code; you could use something like `onlyIf { providers.environmentVariable("CI") }`

With the only if go in my generate Java task? Like only if depends on?

just on the tasks you wish to be conditional.  No need to modify the dependencies (doable but trickier and not necessary).

sounds like that would be your generate java task and graphql task.

yea, Gradle is finnicky about captured variables.  Try with this variation:
```tasks.register&lt;GenerateSchemaTask&gt;(graphql) {
  val profile = providers.gradleProperty("profile")
  onlyIf(profile.map { it != "ci" })
  schema(file("./src/datastore.graphqls"))
  federatedSchemaOut(file("./src/main/resources/schema/federated.graphqls"))
  workingDir = file("../../")
  commandLine = mutableListOf("yarn", "generate:graphql")
}```

More details <https://github.com/gradle/gradle/issues/16080|here>.  Seems like the right soln is
```tasks.register&lt;GenerateSchemaTask&gt;(graphql) {
  val profile = providers.gradleProperty("profile").map { it != "ci" }
  onlyIf(profile.isPresent)
  ...
}```

As you now evaluate the provider directly during configuration phase, you could also use traditional way of reading it, btw.

And please, don't ping random people just to get an answer faster, that is pretty rude in practically every community. We are not paid supporters, just users like you. If you want to have more focused people having a look, use an appropriate channel like in this case <#C013WEPGQF9|>

I think
```onlyIf { profile.isPresent }```
is better, the provider is evaluated as late as possible

Indeed for configuration cache reuse it is better, yes.

that specific error is indeed accurate - there is no “wrapper” task in subprojects, it only exists at the root project.  Typically gradle is run from the root of the project tree, e.g. `./gradlew wrapper` ; tasks in subprojects can be executed like `./gradlew :subproject:task`

&gt; Am I alone, or do other people tangle with this problem?
&gt; 
Actually, I personally think most messages are quite accurate, clear, and helpful. And if I got a message that I find misleading, I open an issue on GitHub to get it changed, or a pull request that changes it.

Regarding the specific case, <@U02S31Y7J2K> already expressed what I also would say. Just one more point, if you would do `gradle :wrapper` it would also have worked from subprojects, as you then explicitly say to run the wrapper task from the root project.

After much reflection, I think part of the problem I am experiencing is
1. We have a _*Big*_ mono repo
2. It is a _*Big*_ Ball Of Mud
3. I load the whole thing into IntelliJ
    a. This is probably a bad idea because this make IntelliJ unstable
    b. IntelliJ passes on some of this instability to Gradle
    c. The behaviour of Gradle is different under IntelliJ than from the command line
        i. I often see Gradle throwing ConcurrentModificationExceptions :astonished:
        ii. I would have thought Gradle was thread-safe, but maybe running under IntelliJ it is not? :face_with_raised_eyebrow:
After moving to a cleaner environment, I can update the Gradle wrapper without problems. So, Gradle was in some state in my previous environment where it was unstable.

Anyway, I have only been using Gradle for about a year, whereas I have used Maven since 2010. While Maven can be ugly sometimes, I find the diagnostics and support substantially more mature. I hope there is some place we can buy live support for Gradle, as it is not a good use of my time troubleshooting the many Gradle problems I encounter daily. I am meeting with some Gradle people this afternoon about Gradle Enterprise.

&gt; 1. IntelliJ passes on some of this instability to Gradle
Never seen that, but well, I don't use such mono repos.
&gt; 1. The behaviour of Gradle is different under IntelliJ than from the command line
Generally, this should not be the case. If you really find such problems, report to the proper place to get them fixed
&gt; I often see Gradle throwing ConcurrentModificationExceptions :astonished:
I've never seen it doing that and I'm using Gradle since pre-1.0.
Maybe it is not Gradle but some plugin you are using?
&gt; I would have thought Gradle was thread-safe,
Should be, yes, if not, you should report it.
&gt; but maybe running under IntelliJ it is not?
Unlikely, IntelliJ just uses the tooling API to drive a Gradle daemon just like the commandline client does. (plus some code injected via init script)
&gt; After moving to a cleaner environment, I can update the Gradle wrapper without problems. So, Gradle was in some state in my previous environment where it was unstable.
Honestly, I really doubt that. I think where you test now you just test in the root project (could also be the root project of an included build if you also use composite builds).
I cannot really imagine what could break to cause what you described, especially as what you described is the normal and expected behavior as we tried to explain already.
&gt; I find the diagnostics and support substantially more mature.
Well, opinions and views can majorly differ, I'm on the complete contrary side.

then it tells me the constructor should be annotated with `@Inject`

can't tell which way is progress :stuck_out_tongue:

looks like a constructor injection issue - try `abstract class GenerateFederatedGraphqlSchema : Exec() {`

what is `graphql` in `register()`? if you're not taking any parameters then there shouldn't be any given

from a past gist that’s a const string - the task name.

ah right, I usually use `registering` which derives the name automatically

<@U02S31Y7J2K> that's the remove `@Inject` that I did :wink: it just tells me it should be

that’s not right.  with no constructor parameters there’s no need to annotate.  Have many custom tasks w/ no constructor params (not even sure how to provide params to inject into the constructor - guess you could do the canned services I suppose).

```internal abstract class GenerateJarProperties : DefaultTask() {```

I mean.. idk, but that's the error it gives me

I remove inject, it complains about it not being there, I add it, it gives me this error

remove not just the annotation - the bogus, empty `constructor()`

didn't happen until I added an @TaskAction... and converted those method's to val's

I removed `@Inject constructor()` and then it says inject should be on the constructor

`exec` and `file` implicitly capture them from build script scope, which the compiler handles by adding hidden parameters

lovely.  Looking closer at this - it doesn’t need to subclass Exec, should inject ExecOperations

this works (and doesn't require `@Inject constructor()`):
```    @TaskAction
    fun action() {
        workingDir = project.file("../../")
        project.exec {
            commandLine = mutableListOf("yarn", "generate:graphql")
        }
        project.exec {
            commandLine = mutableListOf("yarn", "prettier", "--write", outputSchema.get().asFile.path)
        }
    }```

but yeah, as Chris says, it would be better to inject ExecOperations and ProjectLayout, extending DefaultTask, than to use project and Exec

Something like this:
```

abstract class GenerateFederatedGraphqlSchema : DefaultTask {
  @get:Inject
  protected abstract val execOps : ExecOperations

  @get:Inject
  protected abstract val layout : ProjectLayout

  @get:SkipWhenEmpty
  @get:InputFiles
  @get:PathSensitive(PathSensitivity.RELATIVE)
  abstract val sourceFiles: ConfigurableFileCollection

  @get:OutputFile
  abstract val outputSchema: RegularFileProperty

  @TaskAction
  fun action() {
    workingDir = layout.projectDirectory.file("../../")
    execOps.exec {
      commandLine = mutableListOf("yarn", "generate:graphql")
    }
    execOps.exec {
      commandLine = mutableListOf("yarn", "prettier", "--write", outputSchema.get().asFile.path)
    }
  }
}```

you'd have seen the error immediately if this were defined outside of a build script

indeed.  confused me for a moment seeing a random `file` in a custom task…

had to fix a couple of other things along the way, working now, thanks guys

Has anybody seen this exception in Gradle 7.5.1? <https://github.com/gradle/gradle/issues/22320>

You can try `matchingFallbacks = ["debug"]` in your app staging buildtype. <https://developer.android.com/reference/tools/gradle-api/4.1/com/android/build/api/dsl/BuildType#matchingfallbacks>

yes, matching fallbacks is what you need here (I'm the author of the dependency analysis plugin)

Ah that makes a lot of sense, I wasn't aware of that feature. Thank you both! And thank you for the awesome plugin Tony, I'm learning so much about how I'm structuring my modules. Even turned a couple of them to JVM only after some encouragement from you <https://twitter.com/AutonomousApps/status/1573359365280927744?t=fsvUDCh8Sl7FY0InSS5G4A&amp;s=19|on Twitter> and this plugin helping me understand when I am safely able to do so!

I know this is out of the scope of the original question, but if anyone happens to know, I would optimally not even want my Android library modules to have a release or a debug variant, like even now I don't know if  it's make a difference to set matchingFallbacks to debug or release. For those modules there's no difference between the two, only for my app module.
So can I do that somehow? And if not, what *would* actually be the difference if I set the matching fallbacks to release instead?

your android library modules must have at least one variant - that's just how AGP works. One of those types is always created by default (I forget which). You can find out by removing the build types block from one of your modules and then seeing what tasks are available on it

Hmm just tried it and it seems like *both* debug and release types are generated by default. With a minimal build.gradle.kts file like this
```plugins {
  alias(libs.plugins.androidLibrary)
  alias(libs.plugins.kotlin)
}

android {
  defaultConfig {
    minSdk = 23
    compileSdk = 33
    targetSdk = 33
  }
  compileOptions {
    sourceCompatibility = JavaVersion.VERSION_11
    targetCompatibility = JavaVersion.VERSION_11
  }
  kotlinOptions {
    jvmTarget = JavaVersion.VERSION_11.toString()
  }
}```
I get both `compileDebugSources` and `compileReleaseSources` and so on.

That’s quite odd imo, I don’t see how most libraries need to have more than one buildType, must be missing smth.
Now just need to check if I can opt out of that or just accept that I’ll have both of them :man-shrugging:

I guess it's possible that has changed since I last checked :thinking_face: You can disable variants with a variant filter

<@U03FBR224AE> android libraries have debug and release buildTypes which is useful for most developers. The debug buildType will have have debug tools enabled to add breakpoints etc with a perf penalty, and can use a locally generated signing key. The release buildType is meant for consumer with minimum size footprint and best perf.
As Tony said you can use a variantFilter to ignore variants.

Hi <@U0463M5RS2U>, are you talking about <http://scans.gradle.com|scans.gradle.com> or are you a Gradle Enterprise customer ?

I’m talking about <http://scans.gradle.com|scans.gradle.com>

I receive only emails, which show that build was delayed (screenshot in attachments).

Everything was fine the day before yesterday: scans activated shortly after I clicked on activation button. But starting from yesterday’s evening, all build scans were delayed, and none of them activated.

Ok and that is still occurring now ? I'll check with operations if there is a high load on the system.

Yep, I’m still experiencing this issue.
Thank you!

Can you send me the link of the delayed Build Scan ?

There were some unusual errors yesterday but today everything should work out well.

Summary of our private messages: Slow upload might be an issue. Mikhail will investigate further.

Well I want to disable configuration cache but enable write locks. I suppose I could simply self-exec gradle again

have you considered <https://docs.gradle.org/current/javadoc/org/gradle/api/Task.html#notCompatibleWithConfigurationCache-java.lang.String-|this>?

If you self-exec, I'd recommend you use the tooling api in a custom task, not the `GradleBuild` task type. Because if you have a `GradleBuild` task type, you immediately disqualify for composite builds. Using the tooling api it works fine though.

Didn't know it existed. Which is why I asked the question. Is there an API to enable write locks?

what sort of write locks are you referring to?

Laziness <https://melix.github.io/blog/2022/05/gradle-laziness.html>

Thought so, thanks. I kind of wish they would Mark which are which in the javadoc

agreed, the distinction across the Gradle API between eager/lazy is not at all clear.  there was a rant somewhere on here a ways back with suggestions that Gradle should both clearly mark lazy/eager API methods, and deprecate / emit warnings when using eager methods.

&gt; emit warnings
would love if this was opt-in

I'd be just happy if it was on the javadoc

Then at least I could find the information

Unfortunately a warning on eager API is not so easy. Currently basically only the tasks container is designed to be lazy. There were cases already where the lazy API was used on a container and then the logic did not work because noone triggered the lazy handling anymore.

So currently `all` and `configureEach` on built-in containers should not really make a difference except on the tasks container.

I would also say that I had a task that I had accidentally forgotten to make lazy... I made it lazy and our build time went from 5 minutes to 7. Thanks kotlin compiler...

Hi Everyone,

I'm currently running a react-native project on CircleCI.  In that project, I have Sentry that hooks up in the build process to generate sourcemap and upload it to Sentry.

like this : apply from: "../../node_modules/@sentry/react-native/sentry.gradle"

I want to know if there's a way to add debug log to only the sentry.gradle file ?

While I prefer the build logic in an included build instead of `buildSrc`, both works perfectly fine here in regards to IntelliJ. Can you throw together a quick MCVE that shows red for you so I can see whether it shows red here too or whether it is a problem local to your environment?

oh it seems that with the latest idea version it currently does not show my scripts in red. but it still inspects the autogenerated classes when I run “inspect code”. does that also work for you?

Actually I'm not yet on latest but still on 2021.3 :disappointed:
But yeah, those folders are marked as source root, not generated source root.
So yes, inspect code inspects them, unless I mark them as generated source root.

oh is that the underlying issue? can I just change that in project structure? I guess a gradle reimport overwrites it again?

Yes, that's the underlying issue.
Whoever registers the source root should also configure the `idea` plugin so that the source is configured as generated source root.
You can mark it manually, yes.
I would have expected that a reimport overwrites it, yes.
But from a quick try it indeed survived the reimport.

Alternatively you can configure it via the `idea` plugin configuration if you don't mind having IDE specific config in your build script

I’m happy with any fix that works, thanks for the pointer!

&gt; *Vampire*  [3:06 PM]
&gt; While I prefer the build logic in an included build instead of `buildSrc`
btw what do you mean by that? included build as in includeBuild as in composite build? can you point me to an example project?

&gt; btw what do you mean by that? included build as in includeBuild as in composite build?
yes
&gt; can you point me to an example project?
While there are many out there , I don't have one "at hand" right now.
But what do you need an example for?
It's basically not more than renaming `buildSrc` to something different, for example `build-logic` or `gradle/build-logic` or whatever you like and adding an `includeBuild` to your settings script.
One slight difference is, that you do not get type-safe accessors for the plugins anymore but have to apply them by ID, or you have to have a settings plugin (even a no-op) to get them with an included build.

thanks. i was just confused, I was actually already using build logic in a composite build in a monorepo on a contract I worked on.

about excluding the generated sources via the idea plugin, I can not get that to work. I tried adding this to my buildSrc/build.gradle.kts:
```idea {
    module {
        generatedSourceDirs.add(File(buildDir, "generated-sources/dsl-accessors/kotlin"))
    }
}```
but it does not seem to work

<@URQ797WRW> do you know how to fix this?

Hard to guess without hands-on.
One thing is, did you try to completely delete the IDE files and reimport the project freshly?
At least in the past sometimes IJ did not properly switch the type after the initali import if it changed in the build script.
I also reported it in YouTrack, but I thought it was resolved at some point, but I might misremember about the last part.

I'm not sure what you mean.
If you mean you want to add a classifier to a version catalog then no, that's out of scope of the version catalog.
If you mean to specify the classifier where the version catalog accessor is used, then yes.

Either or? How would you add the classifier where it's used?

```implementation(libs.yourlib) {
    artifact {
        classifier = "whatever"
    }
}```

I don't think a classifier makes sense in case of a plugin?

Oh you're right... I'm tired I've worked way too many hours this week. I'm thinking of an annotation processor thing, which quite often comes with plugins. In this case kapt

The alias is an alias for the id which resolves to the marker artifact which resolves to the code artifact.
If you need something with classifier (which you shouldn't) you probably use the legacy way using dependency in the buildscript block and there you have the same syntax available

Yeah, no it's just a library I pass to  kapt

hmm.  only difference from a working config is `.all` vs `.configureEach` (eager vs lazy, which isn’t material for configurations).
```    configurations.all {
        if (state == Configuration.State.UNRESOLVED) {
            resolutionStrategy {
                // force latest.release (and other dynamic versions) to refresh
                // this allows for emergency changes, like realigning artifact versions with CVEs
                cacheDynamicVersionsFor(2, TimeUnit.HOURS)

                // snapshots
                cacheChangingModulesFor(5, TimeUnit.MINUTES)
            }
        }
    }```

should I have a 2nd one? and is dynamic versions snapshots or is that changing modules?

like one with configure each for the other stuff?

changing modules is snapshots, e.g. `-SNAPSHOT`releases.  dynamic versions is `1.+`, for example.

note this will work for dependencies in the dependencies block - not plugin dependencies, for that you need to repeat in a buildscript block.

thought so, plugins isn't a problem fortunately

should be able to do all your stuff in `configurations.all`

thanks, why are we checking state unresolved there?

fixes interactions with other plugins that may use their own configurations and resolve them earlier, which causes an exception if you then try to tweak the config.  no harm in leaving it there, it works in all the normal cases.

ah, yeah, just wasn't sure what it meant :wink:

urgh.. it's still not getting the local snapshots. I"ve tried blowing away my ~/.gradle directory and it's still getting from the remote

there's even one jar that's only local that it's not getting

only thing that seems suspect is the jar's are marked 1.8 or 11 in the maven-local.pom (or whatever) in the ~/.m2

<https://gist.github.com/xenoterracide/8196a954b83b06a8cc6c9c9c8dc53edc>

sorry, I got drug into a super long meeting

isn't that what the code is doing? also I finally got it to output this error.

<https://gist.github.com/xenoterracide/a5200fc5bff5fae969d2ceba3761589a>

seems to be getting those from java.toolchain.version ... but why would that affect the version output. I just removed that and it's fine now

I don't remember, is it a dedicated task type? Then for now until they made it compatible, mark them by type as incompatible with CC

Yeah but I don't even know how I would get the type... Like the type doesn't seem to be there. I tried get by name but that screwed things up too.

If all goes wrong, you can probably do big hammer method like checking the invoked tasks and if the task name is present there, mark all tasks as incompatible with CC

Can you do that without get by name? In a way that isn't going to blow up

That's why I said check the invoked tasks and configure all tasks to be incompatible with CC

In the start parameters you get from `Gradle`

Intellij injects an init script into your build when it syncs the gradle model, the init script adds the task to download sources and javadocs

They blame Gradle you blame them nothing gets solved

They politely told me that Gradle needs to fix it shit because they only use Gradle apis

Only using Gradle APIs dies not mean it is CC compatible. Can you share that support ticket?

What do you mean by configure? What do you want to configure?

using the `javaFx` DSL from the `org.openjfx.javafxplugin` gradle plugin

And is there a reason you don't want to configure it always?
You can probably configure the extension in a configuration action of the `runGUI` task, so if you do not otherwise break task configuration avoidance it should only be executed if the task is going to be executed too, but this is usually not the best idea but a bit hacky.

Ah, I wanted to have a way to run my application without and with GUI through which command you do to run the program, but I guess I'll stick with a terminal prompt

You usually should not run it through Gradle anyway, Gradle is a build tool, not an application framework. The `run` task is for ruining the application for test and debug purposes. So either make two entrypoint classes, one for GUI, one for console, or determine whether the user runs headless to decide which mode to use, or have done parameter to select a more, or a combination of these.

Ah yes you're right, a parameter should work yes !

it's almost certainly better to have gradle build a startscript and run that outside of gradle - then you're not blocking the gradle daemon while your application is running

That would be the best option imo. To make it even more comfortable you can write a settings plugin (`.settings.gradle(.kts)` extension) that you apply in all `settings.gradle(.kts)` files which uses the newer `dependencyResolutionManagement {}`  to declare the repositories.

For publishing the precompiled script plugins to a repo, you basically only need to add `maven-publish` and configure the repository to publish to. Example / explanation:
<https://github.com/jjohannes/gradle-plugins-howto/commit/publish-plugins#diff-6262d4c69eea52ccb569614180adeb6bdb21dfcda8ace52dbed09ad698f8d0e0>

Pre-compiled settings plugin example that declares a repository:
<https://github.com/jjohannes/understanding-gradle/blob/main/14_Settings_Plugins/my-build-logic/structure-plugins/src/main/kotlin/my-project-structure.settings.gradle.kts#L7-L8|https://github.com/jjohannes/understanding-gradle/blob/main/14_Settings_Plugins/my[…]lugins/src/main/kotlin/my-project-structure.settings.gradle.kts>

<https://docs.gradle.org/release-nightly/release-notes.html|Gradle 7.6> introduces customization in this area.

Nice.
Sad that you still cannot create a toolchain from some local path like a JVM the build constructed.

agreed, instead of fixed-sources (Gradle props that specify environment variables or lists of paths), just provide a `searchLocations` property on the toolchain extension.

What I mean is more dynamic.
The build produces some JDK that will be shipped with the end product and it should already be used by the tests for example, or by the `run` task.
I think I have an open feature request for it somewhere.

<https://github.com/gradle/gradle/issues/16245>

I mean, I think if it can download stuff you should be able to provide a URL. Local path would be nice too... Maybe just a URI and if that's file handling appropriately

No, that wouldn't work out.
With that mechanics the JDK would be "downloaded" the first time and installed into the auto-provision folder.
As long as the major version or another one of the identifying attributes does not change it would be reused and even across projects.

I really need a manually created toolchain instance in that case

generateJava is accessing project, can anyone see anything I might be doing? or would this be a netflix problem <https://gist.github.com/xenoterracide/04f2549235adfad8ef3a49abd41ee30e>

Yes, moving from buildSrc to an included build is the natural move forward (and `gradle init` will do just that in the next version)

just a straight move and includeBuild should do the job?

<https://docs.gradle.org/current/userguide/composite_builds.html#included_plugin_builds>

buildSrc automatically applies the java-gradle-plugin, but if you're already using precompiled plugins then you're already applying another plugin (groovy-gradle-plugin or kotlin-dsl) that itself applies java-gradle-plugin, so it should Just Work™
1. rename buildSrc to, say, build-logic
2. add includeBuild to the settings.gradle/settings.gradle.kts
3. optional but recommended: make sure the new project itself has a settings script

You don't need to publish them. you can use them in local maven also

i'd rather just have them as part of the build and not have any publish means.

will my `buildSrc dependencies`  be included in the class path for gradle? IE i depend on the kotlin plugin to provide conventions in my precompiled scripts

Hey Paul, we will schedule a release in the upcoming days!

Just released: <https://github.com/gradle/gradle-profiler/releases/tag/v0.19.0|Release 0.19.0>.

You are explicitly specifying to run the `clean` task of the root project of the included build.
That is the same as if you would say `./gradlew :clean` in the included build.
There is as far as I know no way yet to do the magic "run the task in all projects that have it if any" that you probably intend.

You can for example make a `clean` task in the root project of that included build that fans out to all the subprojects, or you could make a task in your including build that fans out to the subprojects of the included build.

Setting up the according dependencies is what I meant, there is no automatic fan-out except for the command-line special handling of tasks without a given project-path.

hmm bummer. okay i'll log a feature request

Link it here so people can find it :slightly_smiling_face:

I think I'd rather just move to the included build and run `./gradlew clean` (adjusting path for `gradlew` as needed if you don't have one there), or even simpler: `./gradlew -p path-to-the-included-build clean` .

i did the first suggestion but ran into an issue with gradle cache. I have not tried the `-p` argument, i'll try that!

Because you're creating subprojects referencing sibling directories, the settings.gradle from those other directories are not taken into account. So either add a subproject `:observability:bundle` to `engine`, or better: use composite builds instead: <https://docs.gradle.org/current/userguide/composite_builds.html>

I tried adding `:observability:bundle` to `engine` but that did not work either...

settings.gradle
```include ':observability:bundle'
project(':observability').projectDir = file('../observability')
project(':observability:bundle').projectDir = file('../observability/bundle')```
&gt; eric.kolotyluk@Y2RCV7009N engine % ./gradlew build
&gt; 
&gt; FAILURE: Build failed with an exception.
&gt; 
&gt; * What went wrong:
&gt; Could not determine the dependencies of task ':distTar'.
&gt; &gt; Could not resolve all task dependencies for configuration ':runtimeClasspath'.
&gt;   &gt; Could not resolve project :observability:bundle.
&gt;    Required by:
&gt;      project : &gt; project :common-utils
&gt;    &gt; No matching configuration of project :observability:bundle was found. The consumer was configured to find *a runtime of a library compatible with Java 11, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally* but:
&gt;      - None of the consumable configurations have attributes.
I have tried reading "Composing builds" several times, and it really makes my head hurt. I will try again...

Shouldn't it be `../../observability` rather than `../observability`?

Oh crap... right you are... :face_with_rolling_eyes: thanks... Now I feel stupid... Copy/Paste problems...

This is where better diagnostics in Gradle could help. Such as displaying some context, such as the absolute path of where it is looking for things...

I am still getting

```eric.kolotyluk@Y2RCV7009N engine % ./gradlew build

&gt; Task :common-utils:compileJava
Note: /Users/eric.kolotyluk/git/autonomous-iam/utils/src/main/java/com/forgerock/autoid/jsonTransform/JSLT.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

&gt; Task :jar FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':jar'.
&gt; Entry com/forgerock/autoid/jsonTransform/Module$Factory.class is a duplicate but no duplicate handling strategy has been set. Please refer to <https://docs.gradle.org/7.5.1/dsl/org.gradle.api.tasks.Copy.html#org.gradle.api.tasks.Copy:duplicatesStrategy> for details.```
but I think I know how to fix that...

```        duplicatesStrategy = DuplicatesStrategy.EXCLUDE```
solves that problem :slightly_smiling_face:

Do never ever do that.
A project should always only be part of one build and not included to another build like you do it there. This way your will just get a lot of unexpected behavior and problems.

As Thomas already said - just imho not emphasized enough - you should use composite builds for your use-case.

:face_with_raised_eyebrow:
Hmmm... primarily, I am working in a mono repo, a Big Ball of Mud that was started before I got here... and now I am learning Gradle...

If I understand <@URQ797WRW> and others, we really need to rethink how we are using Gradle... :shushing_face:

I transitioned from Ant to Maven in about 2010, and learned to build things according to Maven principles. I am still relatively new to Gradle. Part of the reason I am having trouble is trying to fathom this BBOM I have inherited, with a Hodge Podge of indiscernible Gradle practices.

Does anyone know of any really well designed Gradle projects that we could look at as examples?

Hopefully the Gradle build itself.
And there is for example also <https://github.com/jjohannes/idiomatic-gradle/> which usually is quite good.

WOW! :partying_face:

This looks awesome... thanks!

Gradle itself wouldn't notify the app if files have changed. This is implemented on the framework level (e.g Micronaut has something like this). So I guess Gradle notes the changes, but the framework doesn't.

Hey <@U046WMDCWQG> ! :smiley::wave:

(Disclaimer: I may have misunderstood you, let me know if that’s the case!)

Is your ‘run’ task (or tasks it depends on) creating a JAR (or binary), creating an image, pushing it to a registry, and updating a replicaset in the cluster?

For a Gradle task in continuous mode to be able to live-update a container deployed in a kubernetes cluster, based on local changes in the app’s sources, would require those steps I mentioned to be modelled as Gradle tasks, and for those tasks’ inputs to be declared and wired into each other appropriately, all the way from ‘farm to table’ (or ‘source file to cluster’, in this case).

The `run` task I know of comes from Gradle’s built-in ‘application’ plugin, and it is a `JavaExec` task, ie it runs `java -jar &lt;some jar&gt;` to start a Java application locally. This out-of-the-box task works well with continuous build because it’s quite simple (it compiles java sources, packages them into a JAR, and then invokes the ‘java’ binary).

Hey <@U024SV6C8JH> :smile:

The `run` task that I’m using is the one that comes with the application. The step of syncing code from my local into the container happens outside of gradle.

That’s why I’m curious why it works on my mac but doesn’t inside the container. I perhaps have to check on other JVM configurations inside the the container