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

Gradle Community

No, that's chicken-and-egg.
To know which tasks are going to be executed all plugins have to be applied and all configuration done, so that the task dependencies can be evaluated, so when the information is available, you cannot change that anymore.

You could check for the explicitly requested tasks in `gradle.startParameters` but be aware that there you will find exactly what was typed, so could be abbreviated for example.

Better always apply the plugin and then do according configuration like using task's `onlyIf { ... }` or similar to skip the tasks.

I would expect
```buildscript {
    dependencies {
        constraints {
            classpath(...)
```
to work

It should if done properly. Also see <https://blog.gradle.org/log4j-vulnerability|https://blog.gradle.org/log4j-vulnerability>

<@URQ797WRW> - not sure if I am missing something, but doing `constraints` did not work on dependencies pulled in by the plugins (works fine for normal dependencies, but if it is coming from a plugin, it seems to be ignored

As you can see in the blog post, it works fine, so maybe you should provide an MCVE :slightly_smiling_face:

(given the information in the blog is correct of course)

weird, we use this for managing transitive vulnerable dependencies in our project, and that works fine, but when I tried to do this to a dependency pulled in via a plugin it seems to have ignored it

I tried to add it in `settings.gradle's`  pluginManagement section, but it refused to recognize the constraints directive

if you want it in `settings.gradle`, try
```gradle.beforeProject {
    buildScript {
        ...```

That wouldn't help much for settings plugins though. But simply using `buildscript { ... }` there should also work

right, you'd need it in the body of the settings script too

Btw. <@U019L3NM4PK> are you aware of a difference between `gradle.allprojects { ... }` and `gradle.beforeProject { ... }` when called from a settings script?

I didn't check at what point `allprojects` runs

Should run immediately for all projects already there and on newly added ones as soon as they are added.
But I think either way before the actual build scripts come into play if I'm not remembering wrongly.

in any case, these constraints aren't inherited from parent to child so you need to apply to all projects afaik

I am clearly missing something - what is the significance of `buildScript` - I thought this is some legacy statement (a lot of instructions mentioning say to use it only with older gradle) , but I starting to think I am wrong

You should not use it to add plugins to the classpath and then apply them using the legacy mechanism

For that you should use the `plugins { ... }` block.

But it is fine to declare dependencies you directly use in the buildscript or to declare dependency constraints for example.

Besides that the need to do the former is a sign that you should move that logic to a custom plugin or custom task instead :slightly_smiling_face:

also if you have a plugin that doesn't have a proper marker, you have to either add the dependency in buildscript (or add resolution rules to pluginManagement). that works _together_ with the plugins block, it's not a full replacement

ok - I am still a bit confused about constraints for plugin - do I need to do this as :
```// in build.gradle
buildScript {
  dependencies {
    constraints {
       ...
    }
  }
}```

that works but only for plugins applied in that project (not other subprojects)

It's `buildscript { ... }` not `buildscriptHierarchy { ... }` :smile:

`buildscript { dependencies { classpath(...) } }` _is_ inherited by child subprojects

For now I just want to get the parent project to work :smile:

&gt; `buildscript { dependencies { classpath(...) } }` _is_ inherited by child subprojects
Only kind of.
It is not really inherited.
It only works on the classpath of the current build script.
This classpath lands on a class loader.
This class loader is the parent of the class loader of the child project buildscript class loader.
And as class loaders first have to ask their parent for a class before serving it themselves, the one would win.
But on the class loader of the child project you could still have the a different version, maybe with vulnerabilities and so on. :slightly_smiling_face:

"kind of" sure, it's classloader inheritance and not extending the buildscript configuration
but classloaders load from their parent *first*, so even if you add a different versioned dependency in a child project's buildscript, for any classes that exist in the parent, you'll get that instead of whatever the child requested

so normally a child project can't add vulnerabilities just by bringing in a dependency different than the parent, unless the issue is in new classes that don't exist in the other version and also somehow don't crash when mixed with old classes

definitely can lead to some unintuitive behavior where the output of `:buildEnvironment` doesn't match what's actually on the classpath though

You never know what people come up with to use vulnerabilities.
The vulnerable jar will be already present and can maybe easily be used by evil-doers.
:man-shrugging:

I wonder if it's in the realm of feasibility for project isolation to break that parent classpath connection and instead use the parent as a "dependency"

I had just submitted it at that point. Just trying to work out a timeline.

Iirc it should be through in 2 - 3 work days

Not 100% sure what you are after, but maybe you just search the `installDist` task?

I need simple way to run my application from the commandline without specify the classpath as Parameters (this part is solved with Class-Path in the Manifest file).
The installDist seem to work, didn’t know that it includes the build task.

As your `main` distribution is configured, I guess you use the `application` plugin. If you do, you should *not* set the `Class-Path` attribute. If you want to run the application from source for testing purpose, either use the `run` task, or `installDist` and then there the start scripts. For productive run, build the distributable archive with `distZip` or `distTar` which you unpack at production site and then again ist the start scripts.

are you perhaps running Gradle itself with Java 8?  Toolchains apply to what your buildscript is compiling - there’s still resolution etc for plugins that will be based on the Gradle JVM.

What’s the response from Artifactory?  is it 404 or 403?

Artifactory will improperly cache responses for artifacts that were not previously present.  it’s typically because the user requesting the missing artifact did not have the “cache permission” to put the new artifact into the repo.  Typically, artifactory admins setup mirrors to pull the new artifact in automatically…but the “missing response” still gets cached and thus when you try resolving the dependency in Gradle, it fails

see this for more info:  <https://jfrog.com/help/r/how-does-the-deploy-permission-relate-to-remote-repositories/how-does-the-deploy-permission-relate-to-remote-repositories>

the workaround is to try requesting a different version of the artifact…this will bust the cache response

then you change it back to the version you want

This failure is not one of artifact resolution, it’s using the resolved artifact metadata to compare capabilities where the failure use.  Gradle is expecting a Java 8 component but receiving a Java 17 one.

just make sure that:
1.  your submodules are using the same jdk17
2. the artifact is actually present in artifactory

<@U02S31Y7J2K> he said, “Have also ensured that the module settings are using the JDK 17. Have also set the java toolchain in each submodule to be 17.”

Correct.  Likely the Gradle JVM is still Java 8 or there’s an otherwise incompatible artifact.

i think that the 1st issue might be the metadata…then he tried to simplify it by just using jdk17 everywhere

the fact he is using jdk17 for all the submodules and still getting the problem makes me think he’s not resolving the right artifact

gradle shouldn’t be expecting a jdk8 artifact if all he is requesting is jdk17 artifacts right?

it will if the Gradle JVM is Java 8 or other dependent artifact require Java 8.

for example, if you are running Gradle on Java 8 but use a plugin that is for Java 17 - that will cause this error.

but he’s setting the java toolchain to 17…you think he’s got a daemon still on 8 or something?

that toolchain is only for compilation tasks.  it doesn’t apply to what Gradle itself is running on for plugins etc.

ok lots of helpful things to dig into...will take a peek and circle back

yup so indeed the jvm for gradle is 1.8 as determined by JAVA_HOME...the issue is all our other repos are legacy so I'd like to be able to specify this specifically for this one repo without clobbering the JAVA_HOME system property

had thought I was solving that with the toolchain route, but clearly not :slightly_smiling_face:

`JAVA_HOME=/whatever ./gradlew` should do it.

that was for the command line.  iirc this works for gradle.properties:
```org.gradle.java.home=/path_to_jdk_directory```

thanks Chris, testing now :slightly_smiling_face:

cool, I think that did the trick...looks like the gradle JVM is still using 1.8 from JAVA_HOME but the gradle.properties being set to 17 seems to be working...that was fun to debug :smile: :smile:

Hi , I was facing relevant issue ..just a quick question on this..if there is a plugin which controls the compatibility of the java version is in sub projects. And the plugin project is on JDK17 , will there be any chance or any property apart from setting gradle.properties to set JDK to 1.8 version??? I tried setting org.gradle.java.home to 1.8 and couldn't get to work it.. thanks in advance

Have you looked at using Gradle java toolchains to provide separate (from what Gradle runs on) java versions as needed?

Using version catalog, `alias()` will add the version as well; this is why Gradle 7.4 relaxed the syntax to allow the version to be used in subprojects when it has the same value as in the parent project: <https://docs.gradle.org/7.4.2/release-notes.html#plugins-can-be-declared-with-a-version-in-a-subproject-in-more-cases>

Now what do you mean by “i cannot use `plugins` in my build logic plugin”? :thinking_face:

&gt; Without version catalog plugins are usually declared with version and apply false.
I wouldn't say "usually".
If you want to centralize plugin versions wihtout version catalog, the usual way is to define the version in `pluginManagement { plugins { ... } }` and then apply without version where you want it.
Declaring the plugin with `apply false` in the root project is usually used to overcome class loader issues.
You can define the version there too though instead.
&gt; Is it enough to apply the plugin and the version will be the one of the matching plug-in ID defined in my version catalog?
The version catalog is just what it name says, a catalog of versions and coordinates to pick from. Just having something in the version catalog does not influence anything. The version is used nowhere and it is applied nowhere.
In a "build logic plugin" you define the dependency / version in the build script of the project that builds that plugin as normal dependency and then you apply it without version in the plugin.

yeah I wouldn't say usual is apply false either...the default is true for a reason...that's the actual usual imo

Sorry for the late reply.

I’m migrating to build logic to setup my project, so I have plugins like this:
```class AndroidHiltConventionPlugin : Plugin&lt;Project&gt; {
    override fun apply(target: Project) {
        with(target) {```
some of these plugins have to bring in other plugins

This is how I’m doing it right now:
```pluginManager.apply("com.android.application")```
The thing is that this syntax here does not allow me to pass a version.

while in my modules I used to do something like this:
```
plugins {
    alias(libs.plugins.android.application)
    alias(libs.plugins.kotlin.android)
}```
using version catalog

I now include my build logic plugins:
```
plugins {
    id("my.buildlogic.android.application")
}```
But the plugin I apply is versionless now.

I cannot use the same syntax in my plugin:
```val libs = extensions.getByType&lt;VersionCatalogsExtension&gt;().named("libs")
val hiltPlugin = libs.findPlugin("dagger-androidHilt").get()
plugins { 
  alias(hiltPlugin)
}```
Because on the `plugins { }` I get this error:
&gt; Using ‘plugins(PluginDependenciesSpec.() -&gt; Unit): Nothing’ is an error. The plugins {} block must not be used here. If you need to apply a plugin imperatively, please use apply&lt;PluginType&gt;() or apply(plugin = “id”) instead.
and the other API (pluginManagement.apply) doesn’t accept a version.

So basically, if I understood your answer: you are telling me, that I should do this in my main `build.gradle.kts`

```plugins {
    alias(libs.plugins.android.application) apply false
    alias(libs.plugins.android.library) apply false
    alias(libs.plugins.kotlin.android) apply false
    // etc…
} ```
is that correct?

If your plugin *depends* on those other plugins, then add them as `dependencies {}` of your plugin (add a dependency to the "plugin marker artifact")
Otherwise yes, use `alias() … apply false` on the consumer side.

Yeah, as Thomas said, to not use the `apply false`, but as I also said above, define them as dependency in your build logic build, so for example `gradle/build-logic/build.gradle.kts` or `buildSrc/build.gradle.kts`, whatever your build logic build is.

I was attempting to model this flow:
1. Task runs some external service
2. That external service returns some data
3. Another task that takes that data, adds a property 
4. Other tasks use the existence of that property in an `onlyIf` block

Have you considered a <https://docs.gradle.org/current/userguide/build_services.html|shared build service> to store the data? Tasks can talk to it to put, mutate, and query the data.

I considered going down this route but this logic would have to interact with a `Project` object which isn't configuration-cache safe AFAIK

what sort of data does the external service return? E.g. A lot of files? Or a REST response with a couple of properties?

okay, cool, and what property does the task in step 3 add? It edits the file’s text content, like find/replacing a version number, or applying a git diff - something like that?

maybe instead of an `onlyIf {}` block you want to just change the other tasks to only process files that contain the property.

```val downloaderTask by tasks.registering { ... }

val processorTask by tasks.registering { ... }

val otherTask by tasks.registering {
  val processedFilesWithProperty = processorTask.map {
      it.outputDirectory.asFileTree.files.filter { file -&gt; 
          "xyzProperty" in file.readText() 
      }
  }
  inputs.files(processedFilesWithProperty)

  doLast {
    val files = processedFilesWithProperty.get()
    // ...
  }
}```


Oh this is a good idea too - thanks, lemme run with this for a second

I - and most projects I know - prefer using concrete versions. And with concrete versions there is no point in using dependency locking. Dependency locking mainly makes sense if you declare dynamic versions, but still want reproducible builds.

I've started using dependency locking at my org recently.

We were having a lot of issues where our SCA tools were flagging dependencies as containing vulnerabilities which failed our builds. It was a lot of manual effort to constantly be updating dependencies to their newest versions.

dependency locking allows us to build jenkins pipelines to run periodically that update the lockfile with the newest versions and opens PRs.

I have dealt with a good amount of configuration difficulties with dependency locking but I've been happy with it.

I would love a way to have concrete versions but an automatic way to update them at the patch, minor, or major level.

I usually use the `versions` plugin of ben manes to display what updates are available and the `refreshVersions` plugin to update the versions.
For me this is a pretty convenient combination and not a pain at all to update versions.
There are also other plugins available that can update versions, and work together with the  `versions` plugin for example to create PRs.
Or if you use `GitHub` for your code, you can use the Renovate bot if you want such PRs I don't like at all, or the not so good Dependabot.

Thanks for those recommendations <@URQ797WRW>! Will  check those plugins out.

Thanks! I also use dependabot in one of my open source projects.

Sometimes dependency locking is used by external tools to determine the actual dependencies of a project, because it's easier than trying to parse the build scripts <https://snyk.io/blog/security-testing-git-based-gradle-projects-lockfile/|https://snyk.io/blog/security-testing-git-based-gradle-projects-lockfile/>

Which is both bad. The tooling API should be used to get the information. That's the only really reliable source.

That's a rather complex topic.
I tried to explain it further in a comment on that issue.
Put short, if the current process is compatible enough to run the build, and the option is used, no daemon will be started.

The question is, why do you need it, what is your problem with the single-use daemon, or even with a long-lived daemon?

it's a legacy CI pipeline which has used --no-daemon since before using a daemon was the recommendation.

The daemon fails to terminate when using the artifactory Jenkins plugin despite success, so the build hangs. Solving that issue has proven very complex but would be the right way to do things, I was hoping to make as minimal changes as possible during the gradle 7-&gt; 8 update.

You probably just need to add the instrumentation agent argument

yeah adding that argument works it just felt like I was going down the wrong path

Yeah, no.
If you want the build to run in the current process, it has to be compatible.
And that means either the agent must be there, or disabled and the latter is a very bad idea.

Well, your application returns with exit code 1. This is most likely not a Gradle issue. Run through a debugger and find out where your application does not behave as expected.

Run with `--info` or `--debug` to maybe get more information about what is happening in case it is before the application is actually started.

Hi all, was wondering if there's any other work around people have for this issue (<https://stackoverflow.com/questions/74519672/why-my-gradle-sync-always-download-grooy-xxxx-3-0-9-pom-every-time|stackoverflow fig 1>, <https://stackoverflow.com/questions/76573313/intellij-gradle-sync-re-downloads-groovy-runtime-jars-every-time-groovy-all-gr|stackoverflow fig 2>) which appears to still be a bug in how either gradle or intellij cache groovy runtime jars... Reason I ask is to try to provide my colleagues team with a good first impression as i convince them to switch (which is likely to happen). thanks.

I think you should stray from using `Task.project` as much as possible

agreed, just trying to determine what my situation is currently :slightly_smiling_face:

using `Task.getProject()` or any instance of `Project` is a problem because of Configuration Cache

<https://docs.gradle.org/8.1.1/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution>

Config cache tries to store the Gradle config to disk using Java Serialization, but it can’t store a Project because it’s too big and complicated. But if you’re only running tasks that aren’t loaded from the config cache, then you’re not going to have a problem. But maybe those warnings were coming from Gradle plugins that were updated in 8.1.1 to be Config Cache compatible, or maybe you updated some other plugins as well that also fixed Config Cache problems?

ok but again, that doesn't address my question

if your build is running okay then there’s no problem :+1: But yes, the “don’t use Project” restriction still applies.

again, I'm skeptical that it's "running ok" because this was a warning in 7.6 that it would cause deprecation failure and that didn't seem to happen...because there's a disconnect I'm looking for some verification from the gradle community about whether or not this deprecation failure should have happened or not

<https://docs.gradle.org/current/userguide/upgrading_version_7.html#task_project>

&gt; Calling Task.getProject() from a task action at execution time is now deprecated and will be made an error in Gradle 8.0. This method can be used during configuration time, but it is recommended to avoid doing this.


if you read my original question, I stated that have deprecation warnings about task.project in gradle 7.6, yet I was able to upgrade to 8.1.1 without encountering any build errors.

This is not consistent with my expectations, so I am seeking clarification about whether this should have actually failed, or if it is no longer a build error in gradle 8.1.1

what sort of clarification are you looking for? I’m not sure what else can answer your question more than a link to the docs

I stated what I'm trying to get for clarification...if you can only link me to the docs, then kindly wait for someone else to answer

do you know what the causes were for the warnings you saw?

Did you enable the `STABLE_CONFIGURATION_CACHE` feature preview when on 7.6 and removed this during the upgrade to 8.1.1?

Iirc that deprecation warning only comes if you enable that feature preview and if you enable configuration cache with Gradle 8 it should indeed fail iirc.

yes, it's enabled in gradle.settings but set to false in our gradle.properties

that's an easy test then, I'll enable it in my 8.1.1 env and that should fail

otherwise looks like the 8.1.1 upgrade is fine, but our config caching will be busted...no surprise...super legacy project that needs a *LOT* of TLC

Actually if `STABLE_CONFIGURATION_CACHE` is still enabled, you should still get the depreaction warning even if you disabled the configuration cache.

I just tried with 8.1.1.
Without the preview feature and without CC =&gt; all green
With the preview feature and without CC =&gt; deprecation warning
With CC =&gt; failure

If you have the feature enabled but do not get the deprecation warning, you most probably do not reach the code path where the project instance is used at execution time, for example because the task being up-to-date or served from-cache

interesting ok...I might want to just remove it to be safe then until I can rewrite the plugins responsible for that pesky task.project stuff

Looks like there is a problem while communicating with the Kotlin Compile Daemon to me. But whether that has anything to do with slower build I don't know.

ah nvm... I think I can use this
```println providers.gradleProperty('gradlePropertiesProp').get()```


Not really. Despite its name this does not return Gradle properties, but only project properties. There are slight differences between those two and you only get what you expect if the project property happens to have the same value as the gradle property, for example because you set it through `gradle.properties` and do not override either with another way.

But just run with debug logging, or look at the process list.

Or use the JVM arg `-XshowSettings:vm` if you run a VM that supports it

thanks for the suggestions, i'll give this a shot

you could add an additional action for all publishing tasks that would log the GAV to console

```tasks.withType&lt;AbstractPublishToMaven&gt;().configureEach {
    val publicationGAV = provider { publication?.run { "$group:$artifactId:$version" } }
    doLast("log publication GAV") {
        if (publicationGAV.isPresent) {
            logger.lifecycle("[task: ${path}] ${publicationGAV.get()}")
        }
    }
}```
That could be amended to write the GAV to a file too.

alternatively you could try grabbing the generated metadata file. If you run `./gradlew publishToMavenLocal` then take a look in the build dir for something like `build/publications/XYZ/module.json`. Because it’s JSON it’ll be a bit easier to parse than a pom.xml.

That file will be generated by a task named something like ‘generateMetadataFileForXYZPublication’. So you could add a `doLast {}` action, or a separate finalizer task, for all ‘generateMetadataFileForXYZPublication’ tasks that would read the file and log it to console or copy it to a directory for your script to work on...

actually why not just look at the publications extension directly?
```tasks.register("listPublications") {
    doLast {
        for (publication in publishing.publications.filterIsInstance&lt;MavenPublication&gt;()) {
            println("${publication.groupId}:${publication.artifactId}:${publication.version}")
        }
    }
}```

Ah, `publications` , I was trying `configurations` and looking to access the `runtimeElements` and `archives`, and not able to get all the right information. Though using `doLast` might also have helped. But the publishToMavenLocal works just as nicely and won't require gradle files to be modified (will be turning this into a github action to help call promote on the artifact hosting tool and allow us to switch the tool used without needing to rework everyones gradle file. Which is perfect. Many thanks for the pointers. I presume `filterIsInstance` is kotlin? I had to switch the code to the following as I'm using groovy but I presume this is the expected way to achieve the same (my groovy is rusty):
```tasks.register("listPublications") {
    doLast {
        for (publication in publishing.publications.findAll{it instanceof MavenPublication}) {
            println("${publication.groupId}:${publication.artifactId}:${publication.version}")
        }
    }
}```


If I need to switch to handle multiple publications from one project I may switch from getting the json file to printing them out using the above task and run `./gradlew listPublications --console plain --quiet` instead

sounds like a good plan!

&gt; will be turning this into a github action to help call promote on the artifact hosting tool and allow us to switch the tool used without needing to rework everyones gradle file
Just curious: did you consider turning it into a Gradle plugin instead? Then you wouldn’t need to pipe/grep stdout, and you could write it in Kotlin (or Java or Groovy, whatever works best)

We'll have npm, python, generic, and maven artifacts, so having an action to handle this cleanly for projects without needing to expose the backing service too much is probably better for this particular situation. If it was just one or two types then a native plugin/library probably would make sense

You should wire it to neither task.

*Instead* you should define the generation task's output as source directory, then all tasks that need sources automatically get the necessary task dependency.

Otherwise, you need to add explicit task dependencies to all tasks that need the sources and that could be added by arbitrary plugins.

```val yourGenerationTask by tasks.registering...

sourceSets {
    main {
        java {
            srcDir(yourGenerationTask)
        }
    }
}```

I am going to try that, thank you!

I guess it would work with Kotlin APIs too? thinking in the kotlin custom dsl for KMP as root source sets don't work on kmp

Executing `./gradlew compileKotlin --dry-run` should show the task if it was added as `srcDir`?

For Kotlin/JVM this was handled in <https://youtrack.jetbrains.com/issue/KT-16764/Kotlin-Gradle-plugin-should-replicate-task-dependencies-of-Java-source-directories> it seems.
Maybe they did not properly do it for KMP

yeah, on kotlin jvm, the Gradle official source sets are mapped to the Kotlin ones, but with kmp the sets are empty but the kotlin ones have the info

If it does not work on those, I'd say you should report that, so they can fix that.

I am getting a stack overflow because I am getting the kotlin generated dir from the kotlin src dirs, and I am setting the task as input of a kotlin source set.

Is there any strategy for this use case? I would want to avoid hardcoding the generated dir and instead filter based on the existents ones

I'm not fully getting.
Do you mean your generation depends on the other source files?

From other part, it is added to the kotlin source dirs of the `main` set the directory `build/generated/main` (or whatever)

In order to be able to use it on the task, I am getting it from the kotlin extension too. This mix is generating a stack overflow

I'm still not fully getting.
But it sounds like you try to generate into a common folder.
Don't do that.
Never, ever, ever, ever have tasks with overlapping outputs.

However the documentation here confuses me
&gt; Put a file that ends with .gradle (or .init.gradle.kts for Kotlin) in the $GRADLE_HOME/init.d/ directory, in the Gradle distribution.  
Does this mean, that I cannot use a custom `GRADLE_HOME` env variable?

Correct I think, `GRADLE_HOME` is just a placeholder for the Gradle distribution. If you want to place an init script there, you need to build a custom distribution, or make sure the distribution is at the proper place in the Docker image and add the init script to that.

But the `GRADLE_USER_HOME` should anyway be constant within the Docker image, shouldn't it?

Or to elaborate on my purpose,  is there way I can define an initializtion script at system level. And then allow custom GRADLE_USER_HOME configs so that users can define their own cache directories.

True, but it would be possible to override the GRADLE_USER_HOME directory. It would also have been possible to override the GRADLE_HOME too had that been possible to define explicitly. but I was hoping to incorporate both set of custom configurations. what a project  wants to use/define and also a org specific configuration.

Well, as I said. org-specific configuration you would usually either do by just having a plugin that you apply to all your projects, or by having a custom distribution with an init script that all your projects have to use. Within the Docker image you can as I said of course put it into the unpacked distribution instead of building a custom distribution if always that Docker image is used to run builds. If executing builds locally without Docker should be supported, a custom distribution might be more appropriate. But either way, the projects have to use your custom stuff, either the docker image, or the custom distribution, or the plugin.

Thanks ,that works.. Given this is only a CI specific requirement (of having an equivalent of maven's repository mirrors), I'm inclining towards having this as an init script in the docker image instead of bundling this into a custom gradle distribution.  I cannot add this to the unpacked distribution since I'd expect different projects with different gradle versions too.
I had initially considered the  plugin approach too, but I was trying to set this up in a non intrusive manner.

If it is CI-specific, you could also make sure you call `./gradlew -I yourinitscript ...`

For some more context, I'm trying to setup internal mirrors for the repositories that we commonly use.
1. How a project initializes their builds would not be uniform (so I may not be able to enforce the usage of `./gradlew -I` ) 
2. The gradle distribution and version used may also vary across proejcts
3. The path for gradle user home dir may also vary based on the caching path specified by the project's CI configuration. 
Seems like an org convention plugin may be the way to go here.  Do let me know if you think there could be a better way to handle this.

I am getting below error when I try building my project.

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, well the error tells you most likely that you use the `com.moowork.node` with a Gradle version it is not compatible with (i.e. 6+) and that you should replace it with the `com.github.node-gradle.node` plugin.

I updated it and ran but got below  warning.

npm WARN notice [SECURITY] npm has the following vulnerabilities: 4 high, 1 moderate. Go here for more details: <https://github.com/advisories?query=npm> - Run `npm i npm@latest -g` to upgrade your npm version, and then `npm audit` to get more info.

yes, those are security warnings that you will need to decide how to action.

It is first of all no longer a Gradle topic. :slightly_smiling_face:

Gradle calls npm, npm gives you a warning.

The warning tells you to use a newer npm version.
The plugin you use uses some default npm version.
If you want to use a newer npm version, configure your node plugin to use a newer npm version.

plugins {
  //inlude the nodeJS plugin to execute nodejs and npm tasks
  //id "com.moowork.node" version "1.2.0"
  id("com.github.node-gradle.node") version "5.0.0"
}

node {
        download = true
        version = "9.11.1"
        npmVersion = "5.6.0"
}

//declare a build task
task build

//declare a task to create a zip of the app
task zip(type: Zip) {
        from ('.') {
                include "*"
                include "bin/**"
                include "data/**"
                include "node_modules/**"
                include "public/**"
                include "routes/**"
                include "views/**"
        }
        destinationDir(file("dist"))
        baseName "trainSchedule"
}

//declare task dependencies
build.dependsOn zip
zip.dependsOn npm_build
npm_build.dependsOn npm_test
npm_test.dependsOn npmInstall
npm_build.dependsOn npmInstall

Is there a Gradle question hidden somewhere?

```node {
    download = true
    version = "9.11.1"```
<https://github.com/nodejs/release#release-schedule>
End of life: 2018-06-30
```    npmVersion = "5.6.0"```
<https://github.com/npm/cli/releases/tag/v5.6.0>
Tagged Nov 28, 2017

That's not just "old" at that point…

(I otherwise agree with Vampire it's no longer Gradle-related)

npm_build is getting failed while using build.gradle file. I am attaching the build.gradle file. Kindly help me to get npm build command.

plugins {
  //inlude the nodeJS plugin to execute nodejs and npm tasks
  id "com.moowork.node" version "1.2.0"
}

node {
	download = true
	version = "9.11.1"
	npmVersion = "5.6.0"
}

//declare a build task
task build

//declare a task to create a zip of the app
task zip(type: Zip) {
	from ('.') {
		include "*"
		include "bin/**"
		include "data/**"
		include "node_modules/**"
		include "public/**"
		include "routes/**"
		include "views/**"
	}
	destinationDir(file("dist"))
	baseName "trainSchedule"
}

//declare task dependencies
build.dependsOn zip
zip.dependsOn npm_build
npm_build.dependsOn npm_test
npm_test.dependsOn npmInstall
npm_build.dependsOn npmInstall

This is a Node issue (most likely something to do with the tools your Node build is using: webpack? whatever)
You should ask on StackOverflow or a Node (or whatever is actually failing) community.
But be prepared to be told to update your build first.

This is still not the least Gradle releated.

You did not even include any error message

npm run build command is getting executed when I run from command line

when I give ./gradlew build with the build.gradle file shared above

is there any sample build.gradle file which contains npm build

You still did not share any error message

<https://github.com/node-gradle/gradle-node-plugin/tree/master/examples>

-bash-4.2$ ./gradlew build
Downloading <https://services.gradle.org/distributions/gradle-7.4.2-bin.zip>
..............................................................................................................
Unzipping /var/lib/jenkins/.gradle/wrapper/dists/gradle-7.4.2-bin/48ivgl02cpt2ed3fh9dbalvx8/gradle-7.4.2-bin.zip to /var/lib/jenkins/.gradle/wrapper/dists/gradle-7.4.2-bin/48ivgl02cpt2ed3fh9dbalvx8
Set executable permissions for: /var/lib/jenkins/.gradle/wrapper/dists/gradle-7.4.2-bin/48ivgl02cpt2ed3fh9dbalvx8/gradle-7.4.2/bin/gradle

Welcome to Gradle 7.4.2!

Here are the highlights of this release:
 - Aggregated test and JaCoCo reports
 - Marking additional test source directories as tests in IntelliJ
 - Support for Adoptium JDKs in Java toolchains

For more details see <https://docs.gradle.org/7.4.2/release-notes.html>

Starting a Gradle Daemon (subsequent builds will be faster)
&lt;-------------&gt; 0% INITIALIZING [2m 4s]
&gt; Evaluating settings

could you please let me know what can be done

Run with `--info` or `--debug` and / or `--scan` to get more information on what is happening

jenkins@ip-172-31-2-76:~/workspace/TrainAvailability_main$ ./gradlew npm_build --info
Initialized native services in: /var/lib/jenkins/.gradle/native
Initialized jansi services in: /var/lib/jenkins/.gradle/native
Removing 0 daemon stop events from registry
Starting a Gradle Daemon, 1 busy Daemon could not be reused, use --status for details
Starting process 'Gradle build daemon'. Working directory: /var/lib/jenkins/.gradle/daemon/7.4.2 Command: /usr/lib/jvm/java-11-openjdk-amd64/bin/java --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.util.concurrent.atomic=ALL-UNNAMED -XX:MaxMetaspaceSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xms256m -Xmx512m -Dfile.encoding=UTF-8 -Duser.country -Duser.language=en -Duser.variant -cp /var/lib/jenkins/.gradle/wrapper/dists/gradle-7.4.2-bin/48ivgl02cpt2ed3fh9dbalvx8/gradle-7.4.2/lib/gradle-launcher-7.4.2.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 7.4.2
Successfully started process 'Gradle build daemon'
An attempt to start the daemon took 2.953 secs.
The client will now receive all logging from the daemon (pid: 1646). The daemon log file: /var/lib/jenkins/.gradle/daemon/7.4.2/daemon-1646.out.log
Starting build in new daemon [memory: 494.9 MiB]
Using 1 worker leases.
Watching the file system is configured to be enabled if available
Now considering [/var/lib/jenkins/workspace/TrainAvailability_main] as hierarchies to watch
File system watching is active
Starting Build
Settings evaluated using settings file '/var/lib/jenkins/workspace/TrainAvailability_main/settings.gradle'.
Projects loaded. Root project using build file '/var/lib/jenkins/workspace/TrainAvailability_main/build.gradle'.
Included projects: [root project 'cicd-pipeline-train-schedule-jenkins']

&gt; Configure project :
Evaluating root project 'cicd-pipeline-train-schedule-jenkins' using build file '/var/lib/jenkins/workspace/TrainAvailability_main/build.gradle'.
Compiling build file '/var/lib/jenkins/workspace/TrainAvailability_main/build.gradle' using SubsetScriptTransformer.
&lt;-------------&gt; 0% CONFIGURING [1m 39s]
&gt; root project &gt; Compiling build file 'build.gradle'

If it needs long at that point, maybe your build agent is just too occupied, either CPU- or RAM-wise?

I am using Amazon Ec2 linux instance t2 micro. Could you please share me how much GB or CPU utilization required for standard execution of gradle build.

There is no "standard", heavily depends on the actual build

As much as it needs?  You know your build - size the server accordingly.  t2.micro instances are metered, if they run out of cpu credits they will peg at 100% cpu.

here If I run in the cloud shell it is executing perfectly. but when I try it through job it is getting stuck

Linux 5.10.184-175.731.amzn2.x86_64 (ip-172-31-40-58.ap-south-1.compute.internal)       07/05/2023      _x86_64_        (1 CPU)

01:31:40 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
01:31:40 PM  all   68.45    0.00    7.48    0.93    0.00    0.14   11.35    0.00    0.00   11.66
01:31:40 PM    0   68.45    0.00    7.48    0.93    0.00    0.14   11.35    0.00    0.00   11.66
[ec2-user@ip-172-31-40-58 ~]$

compare a build `--scan` from running it in the shell vs running it in Jenkins to identify configuration differences.

Besides that `allprojects { ... }` is evil, there is no order guarantee in what you configured. That you include one project later than another does not impose any ordering constraints or guarantees. If your backend depends on artifacts from the frontend, you will have a dependency declared and that will then care about building in the correct order.

The issue is that when I tried to configure the backend processResources task with `from(project(":wiki-frontend-public").tasks.named("bundle"))` , it gave an error, as the task had not yet been created.

And the only documentation I could find for this issue was that include() was specifying the order for subprojects, which many websites seemed to confirm.

Well, it doesn't matter actually, because what you do is unsafe and very bad anyway.
You must not reach into other projects like that.
Even if the configuration would work, it is highly fragile and might break anytime in obvious or not so obvious ways.
See here for ways to do it properly: <https://docs.gradle.org/current/userguide/cross_project_publications.html>

That page seems to cover using other projects in dependencies, but I don't see how it would help me in using task outputs from a different project as input for a separate task.

Exactly like that.
And then you can use the configuration on the consumer side as input to the task.

`from(theConfigurationOnTheConsumerSide)`

```// backend build.gradle.kts
val bundleArtifact by configurations.creating

dependencies {
    implementation(project(":wiki-common"))

    bundleArtifact(project(":wiki-frontend-admin", "bundles"))
    bundleArtifact(project(":wiki-frontend-public", "bundles"))
}

tasks {
    val processResources by getting(Copy::class) {
        from(bundleArtifact)
    }
}

// frontend-* build.gradle.kts
val bundles by configurations.creating

tasks {
    val bundleResources by creating(Copy::class) {
        destinationDir = buildDir.resolve("bundle")

        // ...

        artifacts {
            add(bundles.name, destinationDir)
        }
    }
}```
But it seems backend:processResources doesn't move any of the resources this way.

Besides that you disturb task-configuration avoidance by using `getting` and `creating` instead of `existing` and `registering`, the `artifacts` is misplaced within the  `tasks` closure. And besides that, you use a plain `File` as artifact, that cannot bear any task dependency. Use the task itself as artifact or at least configure the `builtBy` as shown in the documentation, but the former is preferable.

I tried using the task as artifact but that gave an error saying it couldn't be converted to the required type, but I'll try builtBy. What's the purpose of existing and registering? Previously when asking for support I was told to always just use getting and creating.

Well, never ask that person again, that recommendation is total bullshit and the opposite of what is recommended.
You can read about task-configuration avoidance at <https://docs.gradle.org/current/userguide/task_configuration_avoidance.html>
And if you break it, nothing really bad happens, but you wast the time of anyone executing the build that would not need the tasks you broke the avoidance for.

Never use `getting` and `creating` unless you have a really good reason or are on a really ancient version of Gradle.
Otherwise always use `existing` and `registering` unless you have a really good reason not to.

At least on task containers.
For all other containers it doesn't really matter as they are not used in a lazy manner.

Also, usually you do not want a `Copy` task, but a `Sync` task, as that also wipes away stale files. `Copy` is mainly for special cases where you copy into a directory where existing files should be preserved.

Ah, ok, you can only use archive tasks as artifacts directly, yeah, then use `builtBy`

Hm, interestingly, with a `TaskProvider&lt;Copy&gt;` it works, so if you would use `registering` instead of `creating` it works.

This feels strange and is probably a bug on either side though

Ah, it also supports a provider of a task that has exactly one output file, which is the case for the `Copy` or `Sync` task, as the one output file is the directory into which the files are copied, that's why it works with the `TaskProvider` you get from `registering`

I reported the inconsistencies as <https://github.com/gradle/gradle/issues/25569>

Additionally, it seems artifacts don't properly propagate needed updates:
```&gt; Task :wiki-frontend-public:bundleResources
&gt; Task :wiki-backend:processResources UP-TO-DATE  // This depends on the bundleResources artifact, and should NOT be marked up-to-date!```

Then you most probably did something wrong :slightly_smiling_face:

I simply changed everything to use existing/registering and moved
```    artifacts {
        add(bundles.name, bundleResources)  // now using the TaskProvider&lt;Sync&gt;
    }```
outside of the task configuration

Well, if it doesn't work, something still is not right, as it should and does.
You could knit an <https://stackoverflow.com/help/mcve|MCVE> that shows your current try.