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

Gradle Community

<https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:resolved_dependencies>
you should probably look into publishing from resolution result: <https://docs.gradle.org/current/javadoc/org/gradle/api/publish/VariantVersionMappingStrategy.html#fromResolutionResult-->

we do this as we also use dynamic version, in combination with dependency locking. As an added clean up measure, we remove dependencyManagement from the pom file, as it doesn’t necessarily line up with the resolved versions.

we define this inside a plugin, so this is java code:
```// we publish a pom using the resolved versions, so no need to include dependencyManagement here
								((MavenPublication) publication).getPom().withXml(xml -&gt; {
									Node root = xml.asNode();
									NodeList dependencyManagement = (NodeList) root.get("dependencyManagement");
									if (!dependencyManagement.isEmpty()) {
										dependencyManagement.forEach(node -&gt; root.remove((Node) node));
									}
								});```

It's bad practice to publish dynamic versions anyway.

Well, what the error says, you have two publications with the same coordinates. Hard to advise anything without seeing your build script

```class BuildCachePlugin : Plugin&lt;Settings&gt; {
    override fun apply(target: Settings) {
        target.plugins.apply(GradleEnterprisePlugin::class.java)
        // or
        target.pluginManager.apply(GradleEnterprisePlugin::class.java)```

<https://docs.gradle.org/current/javadoc/org/gradle/api/plugins/PluginAware.html#getPlugins--|https://docs.gradle.org/current/javadoc/org/gradle/api/plugins/PluginAware.html#getPlugins-->
&gt; While not deprecated, it is preferred to use the methods of this interface or the `plugin manager` than use the plugin container.

What does your build script look like?
I think your problem is, that if you have the base plugin applied (explicitly or implicitly) you would need to configure the existing`clean` task and if not, create a new `clean` task, but do a mix of these syntax wise.

But the more important question is, why do you have that line at all? Why should the`clean` task of a subproject delete the build directory of the root project? That sounds like a horrible idea.

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, it's impossible to tell what's wrong from what your showed. The only thing that is clear is, that you do not have a Gradle problem, so asking here is wrong. You start a Java process and that exits with non-0 exit code which usually means error. Almost all programs also output that error, just scroll up or debug your program. You could actually ignore the non-0 exit code using Gradle, but it is extremely unlikely that this is what you need.

Using buildSrc is nearly the same, but it has some issues, buildSrc is a special case and any change there will invalidate all the projects.

But you can use precompiled script plugins anyway at a includedBuild

Thanks you for your clear answer cristian :pray: that helped me a lot.

Then, is it clear that a plugin with `includedBuild` is preferred to a `precompiled plugin` in most situations?
If so, what is the reason for the existence of a `precompiled plugin`? Is it just a deprecated feature?

Precompiled plugin is not the same as buildSrc

buildSrc is what you shouldn't use (but in some cases is great)

Precompiled plugin is about using the same DSL you would use to write gradle build scripts

So, you can use precompiled plugins (either in groovy or kotlin)
But what I suggest you is doing it in a includedBuild instead of using buildSrc

Oh, I understand !!
I misunderstood about the precompiled plugin.
Thank you for the detailed explanation! :smiley: :smiley:

Also, in 99% if you use `allprojects { ... }` or `subprojects { ... }` you are doing it wrong. Avoid them wherever you can.

Build_Fail_in_Gradle_project

How can we?
You only showed an error message and we can just echo it.
You are trying to declare a dependency for the configuration `providedRuntime`, but that configuration does not exist.

The `war` plugin adds such a configuration

There is no Gradle problem in what you showed. You simply have compiler errors because your Java code is wrong.

This is a Dart error. Gradle just reports it to you. You'd rather ask a Dart/Flutter forum.

For Flutter support go to <https://flutter.dev/community#community-grid>

`generateDebugLintModel` &lt;-- is this a custom task? it seems like its configuration is going wrong. Without seeing how it’s being created, we won’t be able to provide much insight though

The error appeared right after an update I made of Java and Flutter.
But I downgraded it but the error still remains.
I have no idea what the problem is

well, I would say it’s a flutter issue then, not gradle, so perhaps you can find some help from that community? :shrug:
This error is saying that during the creation of that task there’s a nullpointer. Without any context, we can’t really provide much help here.

Disable the `OmitStackTraceInFastThrow` option using the JVM parameter `-XX:-OmitStackTraceInFastThrow` to get the stack trace of that exception.

We also have a <#C03EM93810S|> specific channel if you need.

If you can add me or send the invite please

the symlinks would be transparent to Gradle.  Could this be modelled as standard inputs (files, directories, configuration that, when changed, triggers the task) and outputs (directories, files that, when different than expected, triggers the task)?

yes, but the problem I've come across is that since Gradle inspects the actual files, Gradle takes a long time to check each node_modules. Our build contains several different node_modules that each can take 20 seconds to check

I haven't tested with symlinked directories (the way pnpm does it) and only have a small test project where I modified a file linked to by a symlink

and as soon as I change the linked file, Gradle considers the task no longer up to date

ok.  two options come to mind:
a) task has a FileCollection of @OutputFiles, where each entry is one of the symlinks;
b) `outputs.upToDateWhen {}` that returns true when all expected symlinks exist.

I'm unsure if I understand `a`. The `pnpm install` task will be the one creating all the files, so I don't know which files will be created by the `pnpm install` task. I don't understand how I can avoid having `outputs.dir("node_modules")`?

Will having them as `output.files()` change the behaviour of the  symlink logic in Gradle's up to date check?

if the criteria is ‘does symlink exist’, and they’re dynamic (not known ahead of time), you could create a custom filecollection that only includes symlinks, using that as @OutputFiles.

"Symlink exists and points to path X" is the full check needed

Since e.g. `@types/bar` differs when it's linked to `/home/user/.pnpm/@types/bar/0.0.1` vs `/home/user/.pnpm/@types/bar/0.0.2`

hmmm.  that’s tricky.  Presumably changing from X -&gt; Y would dirty the build.  Don’t think Gradle’s built-in stuff will work there, as it doesn’t have first-class support for symlinks.  However, you could create a custom object representing a symlink (name, target), a Provider that resolves all the symlinks in &lt;wherever that is&gt;, and use a list of those as @Input to the task.

That sounds like a good idea, but how can I avoid `pnpm run build` getting triggered since Gradle will believe that the output of `pnpm install` has changed? Do the same thing with the outputs (i.e. custom provider) ? Never used a custom provider with files, so I'm not sure about the pitfalls

hmmm.. nvm, I think I get it. I just set the output of `pnpm install` to be a guard file with the hash or something of all the symlinks and their targets

Thanks a lot! I'll try this tomorrow (getting late here)

If `pnpm install` is _really_ fast, then maybe you could do it in the same task as `pnpm run build`, and then use the `pnpm-lock.yaml` as input rather than the `node_modules`.

It is faster than checking up to date. Using pnpm-lock.yaml is a really good idea! Since I always run `pnpm install` (as opposed to how it used to be with `npm ci`), that should always be correct. Thanks!

Throwing the code I wrote and replacing with just a simple `input.file()`. I *like* this

Just a caveat to look out for anyone following in my mud tracks: I will need to investigate what happens when using pnpm workspace dependencies. The `pnpm-lock.yaml` will probably not be updated when an upstream workspace dependency is changed, thus not triggering the build of this subproject. I will most likely have to do `tasks.named("pnpmBuild") { inputs.dir("../../other-project/src/main/javascript") }` to get this to work reliably :disappointed:

.. or maybe `other-project` `pnpmBuild`-task will export a consumable configuration (non-cached) with the javascript output just so I can have that as input for the `pnpmInstall`-task

From experience with the gradle-node-plugin and some larger projects I recommend just letting install do its own thing not caching it or even tracking its state.
Anything after that, add `packages.json` as an input and the install task as a dependency and reap the benefits of caching

We're actually using gradle-node-plugin as well here. When moving to pnpm, we will still use it but basically just to use the npmSetup task (for installing npm).

I don't see how just looking at "package.json" in the build is ~not~ good enough to be cache'able? Like I wrote above, even with `pnpm-lock.yaml` I assume (until I've tested it) that pnpm workspaces will not update neither `pnpm-lock.yaml` nor `package.json` when just a workspace dependency changes.

Ok, progress report: Created something that checks if `pnpm install` is necessary by checking the correct `importers` section of the pnpm-lock.yaml, because `pnpm install` takes about 40 secs. For some reason it's *much* faster when doing every repo by itself compared to all together. Probably something O(N²) in there somewhere with dependencies.

<@U0180MXJYJK> is that something general enough to be relevant for other builds?
If so it would be awesome if it could be contributed to gradle-node-plugin, we just merged a PR adding pnpm support which is going into the next version

Let me try the next version first? Do you have an guesstimate on when it's going to be released? (I won't hold you to it)

I need to do some more work on the tests (since the entire test suite is now too heavy for GitHub actions) so essentially When I Have The Time™ which I hope is during this week or during the weekend at the latest.
That is if I don't find any issues with it, but it's pretty straight-forward so it should be easy to look into.

But if you want to test it out early you can clone the repository and use <https://docs.gradle.org/current/userguide/composite_builds.html#included_plugin_builds|composite builds>

Also, the javascript developers insisted on having it as one task (ie it taking 40 seconds), so I have reverted it to not look in the pnpm-lock, instead just creating a pnpm task in rootProject which is depended upon by the different javascript projects

It's ok to call us crazy and that we're doing a stupid design, but we are working on making this fairly large monorepo which will have multiple docker images and k8s yaml files pop out of it with multiple node and frontends(html+js)

So we will build multiple independent javascript projects where some will require input from Gradle in the form of e.g. .proto-files and graphql-schemas. The best way I've found to handle it is to implement a rootProject pnpmInstall task that Npx/Pnpm tasks will depend on.

so a run would for :project1:frontend:assemble would look something like
```:nodeSetup
:npmSetup
:pnpmSetup
:pnpmInstall
:project1:frontend:nodeSetup
:project1:frontend:npmSetup
:project1:frontend:pnpm_build
:project1:frotnend:assemble```


What we have now "works" even though ofc the npmSetups aren't that nice, and it's on the list to replace `npx` with `pnpm exec` to avoid them

When I started with gradle-node-plugin I worked at a place where each of our npm installs took 30 seconds and we had 4 of them on account of a mono-repo-ish layout (luckily running node projects in parallel)
Normally I'd advocate splitting things into different projects and setup dependencies between them, but each project requiring a `(p)npmInstall` is going to incur a cost, at least until I get around to finishing the build service/worker api stuff

the pnpmInstall cost per project was very low according to my unscientific feeling, especially since you can run `pnpmInstall` parallelized if you run it per project with Gradle. It also allows for better granularity so that I don't need to pnpm install in the project that I don't care about right now. Because even if pnpm just symlinks, any dependency only available in those projects are obviously downloaded only if those projects are pnpmInstall'ed. But meh, moot point. CI will take 30 seconds per job longer and they'll be happy.

As a bonus I can rub their nose in it every time they complain about build times. :wink:

Just to be clear, I'm talking about setting the flag in the root .npmrc `recursive-install=true`

Looking at your source, it seems that our setup would be supported by the pnpm task out-of-box, without duplicating any functionality, so yay! :tada:

Especially like that PnpmExecRunner doesn't depend on `pnpmInstall` :thumbsup:

I would've like to have an option for --frozen-lockfile for `pnpmInstall`, but that's something that isn't available in the plugin's `yarnInstall` either (only available for `npmInstall` via `node { npmInstallCommand = "ci" }`), so that's nothing new.

It might be worth noting that `PnpmExecRunner` is the "Run something through pnpm" and not necessarily a `pnpm exec`, it's the core functionality that wraps Gradle's exec
And unfortunately, unlike `npx` and `pnpm dlx` I think `pnpm exec` would depend on `pnpmInstall` since it runs something from the context of `node_modules` , but `pnpm exec` could probably easily be implemented through a `PnpmTask`

The problem is that we won't nor can't use the `:project1:frontend:pnpmInstall`, we must depend on the root `:pnpmInstall`. But I agree, a `pnpmExec {}` construct that does "the right thing" would be very easy to implement for us, especially as we already have that :smiley:

I'm going to take a short break and then try to replace the plugin with the snapshot version. Never used composite builds for _plugins_, but should be fairly easy

I was wrong. Of course.
`Cannot include build 'gradle-node-plugin' in build 'buildSrc'. This is not supported yet.`

that is a bit trickier, if you're ok with a dirty working directory and you're using kotlin I think you can just copy the entire plugin source-code in there and add the two dependencies to your build-file :grin:

Or you have a perfect opportunity to migrate from `buildSrc` to a composite build :wink:

Nah, I just added `apply(plugin = "org.gradle.maven-publish")` and the run `./gradlew publishToMavenLocal`

We're moving away from a plugin to buildSrc because of a nasty bug in the kotlin compiler that increases our build times and makes the build output useless

Hmm.. is it possible to get PnpmSetupTask to stfu? I used to do the following:
```tasks
    .withType(PnpmTask::class.java)
    .configureEach {
        execOverrides = {
            standardOutput = LogOutputStream(<http://LogLevel.INFO|LogLevel.INFO>, logger)
            errorOutput = LogOutputStream(LogLevel.ERROR, logger)
        }
    }

tasks.withType(PnpmSetupTask::class.java)
    .configureEach {
        execOverrides = {
            standardOutput = NullOutputStream.NULL_OUTPUT_STREAM
        }
    }```

FYI: `--silent` seems to do the trick, and everything works well with new plugin. :+1:

<@U0180MXJYJK> 3.4.0 is released and the only thing added from 3.3.0 is the pnpm support

I don't understand. if users of X are not affected, they can choose different versions of X's dependencies, so what are you trying to enforce?

Trying to enforce the versions for compilation and testImplementation of X. But users of X should still be free to pick whatever version they like.

you can use `enforcedPlatform` when declaring the dependency in any given configuration (compilation, testImplementation as you noted).  Other consumers of the module can choose `platform` or `enforcedPlatform` as they see fit.

ah cool, so I do compileOnly(enforcedPlatform and testImplementation(enforcedPlatform( and then leave it at that. That makes sense

Side note: Don't use `subprojects` block at all

Is there a replacement for `subprojects` block? I have multiple `android.application/android.library` modules and I would like to disable the lint task for only the debug variants in these modules.

Actually practically any `subprojects { ... }`, `allprojects { ... }`, `project(...) { ... }`, `configure(listOfProjects) { ... }`, and similar should be avoided due to various reasons, reaching from being non-idiomatic in current Gradle, over hindering more advanced features like parallel execution or configuration cache by introducing coupling between projects, to decreasing build maintainability.
The way to go is to have convention plugins where you define the common logic and then apply these convention plugins in the concrete build script where you want it to be applied.

Is this something related to `configuration avoidance`? I have read about it and there are some specific APIs that should be avoided. I hope gradle makes all the old APIs deprecated sometime, really confusing.

I guess convention plugins are precompiled script plugins right? Do I have to use `buildSrc` folder to apply these plugins in my current project or is there another way? Would be great if I have the plugin code in my current project and not in a standalone project which I have to maintain separately.

&gt; I guess convention plugins are precompiled script plugins right?
"convention plugins" are plugins that set up conventions (rather than "add functionalities"), "precompiled script plugins" are one way to write them.

Nowadays I'd rather use included builds (in settings.gradle: `pluginManagement { includeBuild("…") }`) than `buildSrc`, but yes, that's the idea: keep them in your project unless you have a good reason to do otherwise.

Thanks Thomas. I'm not a fan of `buildSrc` but to clarify: when I want to write such plugins in my current project, buildSrc is my only option?

No, he just told you that you can use an included build which he and me prefer over `buildSrc`

And no, totally unrelated to configuration avoidance

But isn't `includeBuild`  always an external project?

Standalone project which needs its own repository for maintenance

It is a separate build just like `buildSrc`, but there is nothing hindering you too keep it in the same VCS. I for example often use `gradle/build-logic` as alternative to `buildSrc`

Composite builds are nowadays also a way to structure a complex build tree.

ahh ok so you create a folder structure in your project with the path ../gradle/build-logic and there relies your build that hosts the plugins, is that right?

Sorry I mean _rootProject/gradle/build-logic_

```Myproject
  gradle
    build-logic
      build-logic.gradle.kts
      settings.gradle.kts
    wrapper
      gradle-wrapper.*
  src
  build.gradle.kts
  settings.gradle.kts```

<@URQ797WRW> maybe a trivial question but I just reviewed this older discussion and was wondering if it is legit if I just have a simple convention/precompiled script plugin like this:
```import org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask


tasks.withType&lt;KotlinCompilationTask&lt;*&gt;&gt;().configureEach {
    // Material3 is stable but most of its components are still likely to change
    compilerOptions.freeCompilerArgs.add("-opt-in=androidx.compose.material3.ExperimentalMaterial3Api")
    // Belongs to DialogProperties class
    compilerOptions.freeCompilerArgs.add("-opt-in=androidx.compose.ui.ExperimentalComposeUiApi")
}```
I then apply this plugin to multiple other precompiled plugins to avoid redundant code instead of placing it within a `subprojects` block in the root build.gradle.kts file. Following this practice might end up with a lot of precompiled script plugins with a *few lines* of shared logic code. Would you say this is encouraged/good practice or is it better to have fewer plugin files but with redundant code?

Interesting, how were you able to actually get to this conversation, as it is older than 90 days? o_O

However you like but I'd say more small plugins and less duplication is preferable.

I can review all of my Threads even those from 2021. It's in the top left part of the Slack Desktop app but I think it's also present in the web version of slack
Thanks for your opinion :)

Ah, right. Forgot that the threads stay available.

I have a solution, which is to make a new configuration just for running tasks, taskRuntimeClasspath, and then have things use sourceSets.main + configurations.taskRuntimeClasspath, is this appropriate?

I ran into the same when migrating from spring dep mgmt to using platforms. I felt there was a gap in the documentation related to this, so I opened a ticket to enhance it.
<https://github.com/gradle/gradle/issues/18454>
<https://docs.gradle.org/current/userguide/platforms.html#sub:bom_import>
See the note at the bottom of this section warning about the usage of `enforcedPlatform` in the context of a consumable library.

My advice, and it seems like the gradle team agrees, is to not use `enforcedPlatform` if your component should be consumed by others. `platform` works in much the same way, without enforcing rules on downstream projects.

Instead of injecting dependency management, we do the exact opposite. Write resolved versions in the pom and explicitly remove the dependency management section. See also: <https://gradle-community.slack.com/archives/CAHSN3LDN/p1653648524356049>

With your help I've arrived at a happyish conclusion. I'll detail what I did as it might be useful for others.

I made a configuration 'bom', had compileOnly, testImplementation and runtimeClasspath extendFrom bom. This had the effect that things I declare bom (i.e., actual boms), got used in all the places I wanted, but didn't leak outside of modules. I then modify the pom when I publish.

Thanks for the help!

We use the exact same method to achieve that, we just called it “globalPlatforms”. Conceptually it’s closer to how maven handles boms, by applying them globally, whereas gradle scopes a platform to the configuration it was declared in. In the end it’s about convenience and not having to repeat yourself by declaring the bom over and over again. But I do understand why gradle chose to go the limited scope route. You have a lot more control over it that way.
```val globalPlatforms by configurations.creating {
    isVisible = false
    isCanBeResolved = false
    isCanBeConsumed = false
}
configurations {
    configureEach {
        // resolvable configurations like compileClasspath, runtimeClasspath, ... will inherit global platforms
        // make sure we only apply to java modules
        if (isCanBeResolved &amp;&amp; pluginManager.hasPlugin("java-base")) {
            extendsFrom(globalPlatforms)
        }
    }
}```


No, mainly the cross-project configuration is bad. Collecting information should be ok I think. But on the other hand, things like
```dependencies { implementation subprojects[0].tasks.someOtherJar }```
*are* very bad, even worse than cross-project configuration

the next I do in custom plugin is actually

```custom task ...

dependsOn(subprojectsTasks)```
but this is not a `dependencies {}`. This custom plugin and custom tasks are supposed to be running occasionally.

I believe, your example means smth different. In my case, there is no project dependencies obtained this way. But here is a custom task that should depend on subprojects' tasks given by name.

Even for collecting information you break project isolation right?

I'm doing this for "aggregation": i need to run a task that would depend on every subproject's particular task

What you are doing should be done like the new test aggregator plugin does but I would like to see a really tiny example of it, I asked some time ago but I got no reply I think 

<https://gradle-community.slack.com/archives/CAHSN3LDN/p1653070063367199|https://gradle-community.slack.com/archives/CAHSN3LDN/p1653070063367199>

I don't think the test aggregation plugin pattern applies, as he does not want to get reports or other ouptut from these tasks.
Afair just for `dependsOn` it might be fine.

Or does that task that depends on the others use some output of them?
Then what you do is exactly what is bad.

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

my custom task depends on subprojects' tasks only to enforce running them in order. So, my custom task is kind of "lifecycle" task. It doesn't use any output, because subprojects' tasks would generate all input I need themselves.

in particular, I just need to run `ktlintCheck` for each subproject, but I'd like to do so in one command:

`ktlintCheckAll` (my task)

btw, if you say that depending on subprojects' tasks OUTPUTS is bad - is there any good way to depend on outputs?

running ktLintCheck already runs it in all subprojects 

ok
but my question is how to make my custom tasks

running all tasks for the specified name for all subprojects

what custom tasks?
If you run `gradlew ktLintCheck`, Gradle searches for this task in all projects and executes them.
If you run `gradlew :ktLintCheck` it only runs it in the root project.
So what Javi meant is, that you don't need to add a lifecycle task just to run the same-named task in all subprojects

&gt; btw, if you say that depending on subprojects' tasks OUTPUTS is bad - is there any good way to depend on outputs?
I just gave you the link

<https://app.slack.com/team/URQ797WRW|Vampire>  [14:18 Uhr]
<https://docs.gradle.org/current/userguide/cross_project_publications.html>

&gt; If you run `gradlew ktLintCheck`, Gradle searches for this task in all projects and executes them.
&gt; If you run `gradlew :ktLintCheck` it only runs it in the root project.
this works from CLI

but what if I would like to run a task, that would involve subprojects' tasks?

```root build.gradle

tasks.register("staticAnalysis") {
    dependsOn(tasks.named("ktlintCheck"))
}```
i believe (and I actually observe) that this won't run `ktlintCheck` for each subproject: it only runs it for root project. That's why I add `ktlintCheckAll` :

```tasks.register("ktlintCheckAll").configure {
    rootProject.subprojects.flatMap {
  it.tasks.withType(BaseKtLintCheckTask).matching { t -&gt; t.name == "ktlintCheck" }
}

}```
thus,
```root build.gradle

tasks.register("staticAnalysis") {
    dependsOn(tasks.named("ktlintCheckAll"))
}```
 to enforce running all `ktlintCheck` for all subprojects

you need all sub projects `ktLintCheck` task depends on a `staticAnalysis` task registered in each sub project

so you don't need a root `staticAnalysis` task

you will have that task per module, and when you run that task without passing the module, all your `staticAnalysis` tasks will be executed

makes sense

but still - what if I want a "root" task. How to do so? Am I right?

what you mean is that i have to run the task explicitly w/o specifying a module

same way ktlintCheck is working in all modules when you run it via CLI when you don't indicate a module, all your tasks in all modules will run, and consequently ktlinCheck tasks will run too, if you invoke your task without indicating the module

ok, how to express the intention that I would like to run a task w/o indicating a module, in build.gradle script?

whatever I write would always refer to a project.tasks and a particular task, hence - it would always "indicate a module"

running a CLI command from gradle build script?

how to express

`./gradlew ktlintCheck` instead of `./gradlew :ktlintCheck` in gradle scripts?

you should build "second" in build files, and you can use one or second based on your needs

that means I cannot use "first" in build scripts

Exactly. Well, you need `subprojects` to do it, but usually this should simply not necessary. Why do you want to have a root task that depends on all subproject tasks? Just when you invoke, invoke the right one.

That's more related to <#CJYS1DAP5|> 

But in any case it's about Google services that doesn't declare inputs correctly

right but shouldnt that not be an issue because the optimizations got turned off?

<https://issuetracker.google.com/issues/221191604|https://issuetracker.google.com/issues/221191604>

I think even with optimizations disabled it's still an issue, it just that Gradle says: "I know something is wrong, so as a safety measure I disable my optimizations"

oh damn, I did move to nontransitiveR class recently, thanks!

What makes you think there is a version `5.6.9.Final`?

<https://mvnrepository.com/artifact/org.hibernate/hibernate-gradle-plugin|https://mvnrepository.com/artifact/org.hibernate/hibernate-gradle-plugin>
There is info that hibernate moved to `org.hibernate.orm` which is same as plugin so it can be an issue?

It seems they did not release to plugin portal before 6.0.0 and also did not publish the marker artifact to Maven Central, so you need to add a plugin resolution block in your settings script to map from ID to actual dependency

Something like
```pluginManagement {
    resolutionStrategy {
        eachPlugin {
            if (requested.id.namespace == "org.hibernate.orm") {
                useModule("org.hibernate:hibernate-gradle-plugin:${requested.version}")
            }
        }
    }
}```

Have you tried <https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:up_to_date_checks|untracked> tasks? Unsure if that skips the @Input checks, it may as untracked sidesteps all the state tracking.

Oh, wow - thanks!  No I have not, its the first time I have seen this one.  I usually just look at the table

Oh, and apparently its still new - still incubating

not that that matters for me for this one

For the historical record, that does not work anyway.  Gradle still complains

ugh.  that’s good to know, but unfortunate.

Indeed.  Your thought there seemed reasonable

Still good to know about that one even if it is just for documentation sake

It's not just for documentations sake actually. It skips checks otherwise done. The input and output annotations are used for more things than up-to-date checks though, for example implicit task dependencies.

I get what you are saying in the general case though

This is a long-running interactive task (not my design, so :shrug::skin-tone-3: ).  It shares no input nor output state with other tasks

Besides, aren't implicit dependencies frowned upon now?  I get warnings about them all the time in my plugins now

If you are familar with Quarkus, it is the Quarkus "dev mode" functionality

inferred dependencies are good, implicit (undefined) ones are bad.

No, not properly declared dependencies are a problem if you mean that.
Implicit task dependencies are what rocks.
Explicit task dependencies are a code smell.

Dunno guys, I get warnings about one task relying on properties from other tasks as a "dependency"

implicit and inferred is the same.
Using output of one task as input for another task without having either implicit or explicit dependencies is what is problematic.

what is one example of the problematic case?

tbh I always thought this was a very nice feature of Gradle and now it is gone

Can you show a concrete example of such a message?
If it is the one we have in mind you should definitely fix them

e.g. if one task produces a file as output, Gradle knows this

If you think it was a nice feature, you maybe talk about something different

If I have Task1 which exposes RegularFileProperty let's say... and then Task2 which uses that as input (the same ref) but do not define a dep between them (`task1.dependsOn(task2)`) Gradle complains.

The output / input link implies a dependency

but recently I have found Gradle requiring me to do the explicit def whereas previously it did not

If you get that warning, you are doing something wrong, that's the reason for the warning

The dependency is missing and never was there

well, when i warning next i will be sure to share it here

But regardless, this was something Gradle used to be able to work out itself but recent versison cannot.  So...

Definitely, because using explicit dependency is the frowned upon part. :smile:
Using implicit is still the idiomatic way to go.

&gt; But regardless, this was something Gradle used to be able to work out itself but recent versison cannot. So...
No, that's not true

It just introduced a warning if not done properly

Man, the plugin used to work just fine.  So yeah it did, on some level

oops.  they’ve introduced the warning and the detection of various cases that are fragile.

it may have worked fine, coincidentally, but perhaps broken with say configuration cache that allows parallelism or other future changes (JVM upgrade that changes unspecfied behaviours, etc - who knows what the future holds…)

Anyway, when I get this again (I've fix it as I need and work on my plugins) I'll post

"Man", it was accidental that it worked.
It depended on order of tasks.
If you accidentally always run task A that produces the file first before you run task B that consumes the file, it works fine.

But as soon as this accidental order was not given, it maybe used a stale file, or it failed because it is not there, as the dependency from B to A is not there.

You know "man" has multiple meanings in English.  No need to take it that way

In older versions it maybe seemed like it worked, but was flaky at best. Recent versions try to detect such problems and warn you that something is not correct in your build.

We've always been pretty polite with each other :wink:

&gt; You know "man" has multiple meanings in English. No need to take it that way
I'm not a native speaker, so I might got it wrongly. :slightly_smiling_face:

That's fine.  And maybe it comes down to that.  Dunno.  Like I said, I have fixed all of those, though unfortunately so cannot reproduce it

But unfortunately++ I think my solution so far has been explicit task dependency

If you fixed them by adding explicit task dependencies, you should re-fix them. :slightly_smiling_face:

iirc that is the solution implied by the warning

but regardless, that is all theoretical until i can get the warning again

It says ther is neither an implicit nor explicit dependency which both are fine regarding the problematic situation.
Explicit dependency just is frowned upon as you stated. :slightly_smiling_face:

Here, it really is a shame that you cannot not add the annotations

&gt; Explicit dependency just is frowned upon as you stated.
Now then, *that* would be a good warning :wink:

lol.  yea.  stop with the PC stuff and call it like it is :wink:

Well, we don't even get warnings for not using task configuration avoidance api, so, ....

"task configuration avoidance api" == TaskContainer#register?

`==` is too strong as there is more to it

(getting a bit off topic, but an interesting topic)

yea, the mixture of configuration avoidance stuff is SO VERY CONFUSING, warnings would be helpful.  Even if we needed to opt-in to “I care about the performance and quality of my build script, please help where possible…”

But `register` is part of the task configuration avoidance api, yes

`.register` is one of them.  there are so many different ways to break the laziness.

I already heavily leverage Property, Provider, etc