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

Gradle Community

Depending on what you need to run, build services can be an option: <https://docs.gradle.org/current/userguide/build_services.html>
Otherwise then yes, use a separate Gradle run (I believe it uses the same daemon though, it only blocks the client)

Fwiw, Kotlin/JS does such a thing as a "long running task" though (<https://kotlinlang.org/docs/dev-server-continuous-compilation.html>). Last time I checked, they were using an internal Gradle API for that.

I have multiple JVM (Kotlin) micro-services that communicate with each other. Currently we use IntelliJ run configurations to start them, so each of them requests the build from the daemon, and IntelliJ does the execution (freeing the daemon). We have issues with JDK versions, so we're considering executing everything via the application plugin to use java toolchains. I'm worried this will make builds slower as each module will need its own daemon (since the daemon gets stuck executing the service)

&gt; Fwiw, Kotlin/JS does such a thing as a "long running task" though […]. Last time I checked, they were using an internal Gradle API for that.
This is still the case: <https://github.com/JetBrains/kotlin/blob/9324cf336090deb5292282a512c1c0618a8b0774/libraries/tools/kotlin-gradle-plugin/src/common/kotlin/org/jetbrains/kotlin/gradle/targets/js/webpack/KotlinWebpack.kt#L19-L21|https://github.com/JetBrains/kotlin/blob/9324cf336090deb5292282a512c1c0618a8b0774/[…]org/jetbrains/kotlin/gradle/targets/js/webpack/KotlinWebpack.kt>

&gt; I'm worried this will make builds slower as each module will need its own daemon (since the daemon gets stuck executing the service)
I'm really not sure this is the case. AFAIK, only the client is blocked, waiting for the run task to finish; the same daemon is used for everything though.

Run two such tasks in distinct Gradle invocations, and:
• look if Gradle says it needs to run a new daemon because the previous one cannot be used
• use `./gradlew --status` and/or `jps` or `ps` to tell how many daemons are being used

I just checked, and you're right, even if the client is stuck on a `run` task, no new daemon is started (as long as you wait for the build to finish before starting a new task, of course)

I just tried and it looks like I was actually _wrong_: the daemon for the first build is considered "busy" and a new one is started for the second build. That said, up-to-date checks still make the builds fast, and a Gradle daemon is not _that_ expensive to start (YMMV)

:thinking_face: That's strange, when I tested it it definitely did not start new daemons (or they were killed at the of the build)

To be clear on what I did test:
• in one terminal: `./gradlew :service-a:run`  (an application that starts an embedded Jetty server)
• in another: `./gradlew :service-b:run`  (same kind of app with an embedded Jetty server); Gradle prints that a new daemon is started as another one is busy
• in a third terminal: `./gradlew --status` shows 2 busy daemons
I did not “wait for the build to finish before starting a new task”; the two applications are running in parallel.
note: this is a project that's still using Gradle 7.1; things might possibly be different in newer versions.

I did the same but waited until the first web server was running before starting the second task, then it reuses the first daemon. I'm using 7.2 so I doubt it's very different

Ah yes, I did wait for the first one to be running too (I don't consider that as "wait for the build to finish", as I consider the run task to be part of the build).
Anyway, if your own tests show that it matches your expectations, then feel free to ignore mine :smile:

```repositories {
    maven {
        name = "myMavenRepo"
        url = uri("<https://myMavenRepo.com/android-sdk>")
        credentials {
            username = "secretUsername"
            password = "secretPassword"
        }
    }
}```
What options do i have to stop having to have `secretUsername` and `secretPassword` visible?

A few options:
1. Use Gradle properties, which can be set via the command line, environment variables, or in ~/.gradle/gradle.properties;
2. Pull from environment variables via System.env
3. Use a custom ValueSource to obtain the credentials from &lt;wherever works for you&gt;, which could be a Keychain, API call, etc.

Wrt properties, see <https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:handling_credentials>

```repositories {
    maven {
        name = "myMavenRepo"
        url = uri("<https://myMavenRepo.com/android-sdk>")
        credentials(PasswordCredentials)
    }
}```
then provide `myMavenRepoUsername` and `myMavenRepoPassword` properties

Thanks both. :+1:

That docs link is what I needed.

You can use ejson - <https://github.com/Shopify/ejson|https://github.com/Shopify/ejson>

I wrote a Kotlin implementation of it that can be embedded in a project (not documented unfortunately) - <https://github.com/eygraber/ejson-kotlin|https://github.com/eygraber/ejson-kotlin>

If you’re using an Enterprise hosted Nexus repository, that instance can store the credentials and do the proxy for you.

you’d still need to store the credentials to access Nexus, regardless of whether it is proxying (and authenticating) to other repositories.

That I’d assume would be the case and normally people would have those in methods as above, my comment was more for 3rd party dependencies that require credentials for each of those. For example, pulling from Githubs repositories or a private jfrog instance. You’d be able to keep those credentials out of your build scripts.

With our Nexus repository, read access is open as it’s all on an internal network. It’s publish that requires credentials.

error message:
```org.gradle.api.plugins.UnknownPluginException: Plugin [id: 'app.softwork.gradle.bug.publishedSettingsPlugin'] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Included Builds (None of the included builds contain this plugin)
- Plugin Repositories (plugin dependency must include a version number for this source)```

You probably need to `includeBuild("gradle-logic/plugin-testing")` in your root build settings script.

This works, but with this change, each build isn't independent anymore, is it?

So in theory the classpath of the includedBuild("gradle-logic") is shared with the plugin classpath of the settings file? I still try to figure out why my settings plugin from <https://github.com/hfhbd/testingGradle> does not work in a more complex dependency (the linked project works..). Unfortunately, because the Gradle Enterprise plugin is a settings plugin too, it is not possible to create a build scan with a broken settings script file, is it?

Just that you include a build does not add it to any class path. That's why the settings plugin cannot be found. It either has to be in the class path of the id found in the plugin repositories or included builds. But probably not in builds included by included builds. If you would apply a plugin from `gradle-logic` and that would bring the `plugin-testing` plugin onto the class path as dependency, it would probably be found.

But if including a build does not add the deps to the settings classpath, how does the first sample work? <https://github.com/hfhbd/testingGradle>

Gradle sees that this build will build the plugin with the requested ID, so builds it and adds it to the class path.

If you do not apply the plugin, you will see, that the included build does not get built

Interessting, thanks!
So adding it to the classpath is expected and a feature, not a bug. So final question, how does Gradle see it? And why does it don't work with another dependecy (but simillar project as <https://github.com/hfhbd/testingGradle>)?

How does it see what? And where does it not work?

I have a similar build like <https://github.com/hfhbd/testingGradle> but with other `published` dependency, containg a settings plugin too. I added the dependency to the real artifact notation in the build-logic build script, and want to use the settings plugin in the root settings file, like in the sample. But I always get the error, the settings plugin is not found:
```- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (plugin dependency must include a version number for this source)```
Interessting the line `Included Builds (None of the included builds contain this plugin)` is missing, so how does Gradle "see" which dependency/included build provides the plugin ids? Does Gradle parse the meta-inf/services of each jar?

Or does Gradle use other things, like reading attributes in module file? Because if I add the version for the plugin, the marker artifact is found and the real artifact, the same defined in `build-logic/build.gradle.kts` is found and the plugin is applied (using service loader). How can I debug this behavior?

It neither reads jars, nor module files for plugins by included builds, because they do not exist yet potentially. As I said, the included build is only built if actually needed. From your abstract description I cannot tell, as the abstract description could be imprecise. Show as MCVE what does not work

That's my problem, the minimal reproducer does work, the full project doesn't. I can't publish the full project, but I could send it to you via pm.

kotlinJni-test.zip

This is the consumer project: Ideally, I don't need to specify the version of `id("app.softwork.kobol.versions")` in the rootSettings file.

You cannot apply a plugin in `plugins { ... }` just by adding it to the class path.
You could either apply it in a convention plugin in `build-logic` and apply that convention plugin in your root build,
or you could apply it the legacy way using `apply(plugin = "app.softwork.kobol.versions")` outside the `plugins { ... }` block.

Thank you!
Still curious why this works inside the plugins block here, but its okay :D <https://github.com/hfhbd/testingGradle>

Because there it comes directly from a build that is included in the plugin management block

To be usable from the `plugins { ... }` block the plugin must either come from one of the plugin repositories or built in a build included from the plugin management block

Ah, because I (accidentally) added the `include(":published")` so it uses the local script and not the published one, stupid mistake. Thanks, finally understand why the reproducer works.

build.gradle.kts.kt

this almost gets my desired behavior. but `./gradlew taskTwo` does _not_ execute `taskOne` - which is what I also want

I think only with a `taskThree` that does the actual work. `taskOne` then will be finalized by `taskThree` and `taskTwo` depend on `taskOne`.

Hi I'm working on a building a JNI library with native C++. I'm using the `cpp-library` but running into issues compiling on windows. The build stops with:

```&gt; Task :rtlsdr-jni:compileDebugX86-64Cpp FAILED
g++.exe: fatal error: cannot specify '-o' with '-c', '-S' or '-E' with multiple files
compilation terminated.```
Any ideas?

presumably that means it took 2 seconds for Gradle to start, determine what to build (nothing, in the case of a no-op build), and do it (or not)

min = 0th percentile = greater than 0% of samples
P25 = 25th percentile = greater than 25% of samples
median = 50th percentile = greater than 50% of samples
P75 = 75th percentile = greater than 75% of samples
max = 100th percentile = greater than 100% of samples

in any case, I don't think any single one of these measurements is what you should look at. it's the combination. e.g. if mean is much larger than median, you have some very long-running outliers. if P75 is much higher than median, that's affecting more than 25% of your builds. etc.

Thanks for teaching!

Any ideas why apparently having jetifier enabled is making my builds marginally faster?

every case shows jetifier enabled as being faster... weird. in this project. jetifier isn't actually doing anything. so i guess its possible that it realizes theres nothing to jetifiy and it no ops. so the results are essentially the same. but i was expecting jetifier to be slower

When you say nothing to jettify, have you verified that it isn't needed for other dependencies to work?

yep. I have a project without jetifier. and for the heck of it (trying to learn more about jetifier and gradle profiler) im purposefully adding jetifier back in.

now i went to a project that still needs jetifier. ran gradle profiler. then switched to a branch we have that removes jetifier (updates one dep) and the one with jetifier still ran faster.

weird.

whats the chances gradle profiler is doing something wrong

maybe assembleDebug is the wrong thing to run?

Not aware of a Gradle util for this.  I’ll often create a glob-syntax that translates into regex (for example, this is how Java NIO globs are implemented, see <https://github.com/frohoff/jdk8u-jdk/blob/da0da73ab82ed714dc5be94acd2f0d00fbdfe2e9/src/share/classes/sun/nio/fs/Globs.java#L57|sun.nio.fs.Globs#toRegexPattern>).

Hey <@U03L6DRL1KL>! In fact we just published some blog posts that provide a great introduction:

1. <https://blog.gradle.org/how-gradle-works-1|https://blog.gradle.org/how-gradle-works-1>
2. <https://blog.gradle.org/how-gradle-works-2|https://blog.gradle.org/how-gradle-works-2>

you’ll want to ensure the build cache is disabled (assuming you have it enabled) via `--no-build-cache`

Is there an option to provide a convention value to a `ConfigurableFileCollection`. I want to add a default value to my filecollection but users should be able to override the collection too. Of course you could use `setFrom` to override the "convention" value but this require the user to use `setFrom` too.

`dependencyResolutionManagement` can be shared via a settings plugin. `pluginManagement` comes before plugins are applied naturally, so for that you would need a custom init script and thus most probably a custom Gradle distribution. You could try with a script plugin, but I'm not sure if would work.

&gt; `dependencyResolutionManagement` can be shared via a settings plugin
This would mean that I can't share it with itself though right (without hacks)?

&gt; You could try with a script plugin, but I'm not sure if would work.
Yeah, I was trying this but unfortunately I didn't manage to make it working

I regularly share the repositories with a script plugin. It’s a lot less hassle than trying to set up a settings-plugin

Here’s an example using buildSrc, not included builds, but the principle is the same

the script plugin: <https://github.com/adamko-dev/kotka-streams/blob/main/buildSrc/repositories.settings.gradle.kts>

and then applied:
• <https://github.com/adamko-dev/kotka-streams/blob/41d75816d008226767abf8a0b896b2985369c98f/buildSrc/settings.gradle.kts#L3>
• <https://github.com/adamko-dev/kotka-streams/blob/41d75816d008226767abf8a0b896b2985369c98f/settings.gradle.kts#L13>

Ooh I see. Makes sense. Thanks very much to you both!

&gt; I regularly share the repositories with a script plugin. It’s a lot less hassle than trying to set up a settings-plugin
&gt; Here’s an example using buildSrc, not included builds, but the principle is the same
&gt; the script plugin: <https://github.com/adamko-dev/kotka-streams/blob/main/buildSrc/repositories.settings.gradle.kts>
That is neither a script plugin, nor less hassle than a settings plugin.
It is a precompiled script plugin, that actually *is* a settings plugin.

Please don't confuse this with a script plugin (the things you use with `apply from`)
and a the settings plugin implemented as a full-fledged class.

When I said "settings plugin" I didn't specify how it is implemented, whether it is via precompiled script plugin, or as class in Kotlin, or Java, or Groovy, or Scala or any other JVM language doesn't matter at all.
And when I say script plugin, I really mean script plugins, not precompiled script plugins which are a completely different thing even if called similar and looking similar. :slightly_smiling_face:

Sorry, I don’t follow…

&gt; Please don’t confuse this with a script plugin (the things you use with `apply from`)
but it is applied using `apply(from = ...)`? <https://github.com/adamko-dev/kotka-streams/blob/41d75816d008226767abf8a0b896b2985369c98f/buildSrc/settings.gradle.kts#L3>

And yes, it is a lot less hassle than a settings plugin. <https://github.com/adamko-dev/kafkatorio/blob/82818210753be59daf2f72d7520e51465f160b81/gradle-plugins/settings-plugins/src/main/kotlin/kafkatorio/conventions/settings/repositories.settings.gradle.kts|I’ve done that too> and it’s a pain because IDE support for includedBuilds is limited and flakey, it requires multiple subprojects and trying to set all the includeBuilds in multiple files to play nicely, and debugging it is a pain because Gradle doesn’t bubble up the full errors. The script plugin I wrote is just one file + two `apply()` lines

&gt; but it is applied using `apply(from = ...)`?
Ah sorry, didn't look properly and was confused by you saying "in buildSrc not an included build", because those script plugins are not in anything anyway, they are just directly reference files. :slightly_smiling_face:

&gt; and it’s a pain because IDE support for includedBuilds is limited and flakey
Well, I know that some people still have problems with them in IDE in very special situations.
I use them for years and it is long ago I personally had any problem with included builds in the IDE last. :slightly_smiling_face:

Script plugins come with their own problems, especially class-loader hassles, no way to use type-safe accessors or `plugins { ... ]` block, .....
Just for the repositories it might be ok, but I try to avoid regular script plugins wherever possible. :slightly_smiling_face:

no problem - I guess the filename is confusing too. I named them like that to try and get IntelliJ to help out with auto-complete, but it doesn’t, yet...

And yeah, I never write build-script plugins. But settings-scripts are usually pretty limited and don’t change much, so they’re ‘allowed’. If Gradle had some sort of pre-configured included-build equivalent for settings-plugins, ‘settingsSrc’, then I definitely wouldn’t use setting-scripts.

&gt; I named them like that to try and get IntelliJ to help out with auto-complete,
&gt; 
Would so too, and even the Gradle docs recommend that to get IDE support.

&gt; but it doesn’t, yet...
&gt; 
That's strange when even the docs suggest it should work. Did you add the script as "standalone script"?

&gt; If Gradle had some sort of pre-configured included-build equivalent for settings-plugins, ‘settingsSrc’, then I definitely wouldn’t use setting-scripts.
&gt; 
It used to have, back in time `buildSrc` was built before the settings script was evaluated and you were able to access `buildSrc` stuff from the settings script, but that was changed for some reasons.

But why do you need something pre-configured? Just because you don't like composite builds? Because you just need an `includeBuild` in the plugin management block and a trivial build script that applies the `kotlin-dsl` plugin to replicate the same.

As I can download the link it complains for you just fine, I'd say either it was a server hickup if it works for you now, or if it still does not work would tend to blame some anti-virus tool, proxy, or firewall on your side.

Maybe if your included the main build from the samples build?

Whole main build or just the projects via projectDir?

if main build includes the samples build, and the samples build includes the main build, that is not a circular issue?

Never `include` a project in more than one build, never, ever, ever.
So yes, the whol main build.

And no, just including a build does not add any circulare dependency because it does not any dependency at all.
If you just include build B from build A and A does not depend on anything built by B, nothing from B is built.
So as long as you do not declare a real dependency cycle, you should not get into trouble.

Besides that the question also is, why your main build should depend on samples builds

well, samples build is a included build declared in the main one, but that maybe doesn't mean that it depends on samples?

As I said.
Besides that it is questionable why it even does.

only the tasks that are attached using the idea plugin, if you see test tasks running, some plugin is doing weird things 

And we rely on gradle enterprise for caching

If you add a new module then all modules will be recompiled and all tests will be re-run

Ah okay, you missed the CI + cache part on the OP.

I haven’t used gradle enterprise so I don’t know how it caches 

It caches the same as Gradle local, but it is remote.

it sounds weird, because that is not concept of gradle. if the new module is not a dependency of existing module, why should existing modules rebuilt?

Because the classpath changes by having a change in the settings script.

So yes, if you do dynamic recognition, or even if you have a txt file with the projects to include that you read from the settings script should probably have the desired effect.

Putting asside the caching issue. It is 1 extra step that we need to do every time we add a module. If we made `settings.gradle.kts` dynamic it will mean we have to write less code to add a new module. The question is the file traversal going to be an expensive price to pay?

I am doing that and there are settings plugins that do that too, I guess it depends a lot on the project size

Can you point me to a settings plugin that does that?

Depending on how deeply nested your projects are and how you do the traversal it will probably not be that expense, if you for example only look one directory level deep

&gt; that is a really bad default behavior...
Not really, if classpath changes, you don't know what exactly changed

<https://github.com/pablisco/auto-include>

Unfortunately we need to look several directories deep. I guess I will have to give it smarts when traversing to make it as efficient as possible.

<@URQ797WRW> I think there should be an alternative to add modules without changing the settings script as default behavior based on this problem

&gt; Unfortunately we need to look several directories deep. I guess I will have to give it smarts when traversing to make it as efficient as possible.
Or as I said, just have the list in a separate file and not in the setting script code, so that the classpath does not change just because you add a module

The text file solves incremental build problem, but doesn’t solve boilerplate around adding new module problem. I will try the traversal approach and see how much overhead (if any it adds).

I am curious why nobody from gradle has written a blog post about this. Seems like a common problem.

&gt; <@URQ797WRW> I think there should be an alternative to add modules without changing the settings script as default behavior based on this problem
That's not trivial, a project does not even have to have an own build script to be a valid project, even though it is bad practice.
And traversing the whole tree might be the wrong thing to do as you could also have nested builds using composite builds that should not be included as subprojects and so on.

And if you want that behavior, it is trivial to do such a traversal or put the projects to include in a separate file that you read from the settings script

&gt; I am curious why nobody from gradle has written a blog post about this. Seems like a common problem.
Personally, I don't think it is such a common problem, as the modules that are part of a build usually do not change that often in a typical build.

Yeah but I am not talking about an auto include feature. But a text like file to add modules and Gradle can read, for example a toml file based on they are using it for version catalogs

Feel free to add a feature request for it :slightly_smiling_face:
Besides that it could also be trivially solved as a 3rd party plugin probably.

In Square they are adding tons of modules continuously, I would like to know what they are doing about this issue, cc <@UES7RHBDZ>

We have between 100-200 modules and and using the auto-import plugin doesn’t seem to add significant overhead.

ok, so reason is because of auto-import plugin. We have about 400 modules and we add all of them manually :D

Something like
```task.eachFile { fcd -&gt;
    fcd.relativePath = new RelativePath(true, fcd.relativePath.lastName)
}```
should flattern all paths

Something so, thinking in project isolation support

even if you nest it that way, afterProject runs for all projects, not just rootProject

yeah but I need to add the rest of projects to the root one, I can just do if rootProject != project so rootProject doesn’t add itself 

oh I see what you're trying to do. IMO that's a bad idea for other reasons: you should be explicit about your real dependencies, so that non-api changes can avoid unnecessary recompiles

That was indeed a sample, the real plan is with the new Dokka and Kover approach which requires to add all projects to the root one in order to get the merged report.

```gradle.rootProject {
  val rootProject = this
  gradle.afterProject {
    val project = this
    if (rootProject == project) return
    rootProject.dependencies {
      if (project.pluginManager.hasPlugin("org.jetbrains.kotlinx.kover") {
        add("kover", project)
      }
      // same for Dokka
    }
  }
}```

I'm always open to PRs :slightly_smiling_face: But can you clarify the intent? At first glance it seems strange to expose different classes variants to consumers, when the goal of mrjars is to have a _single_ output for multiple consumers.

I want downstream Java 11 (say) source-sets in the multi-project build to be able to compile against the Java 11 classes and not against the vanilla Java 8 classes. This means that although there is only one variant of the jar which leans on Multi-Release we have multiple variants of the classes directory for the different JVM versions that use regular Gradle variant matching. My main concern here is fixing the compilation of module-info.java in multi-project builds… but in principle there could be other purposes too.

coming back to this… does that make sense as a requirement?

I am not sure it makes sense. When you compile against a library, only the ABI should be considered. And the ABI of different modules should be exactly the same.

The ABI includes the module-info.class though…

if I recall properly `module-info` is only supported within a jar, and it should be in the mrjar under `META-INF/versions/whatever`

Library authors don’t get to make choices… we suffer under the weight of our users choices :disappointed:

let me play with this some more locally then… I didn’t know that the module-info.class had to be in a jar

that's because it defines the unit of what is visible externally. Otherwise potentially you can have classes on classpath in the same package as one in the module...

does it _have_ to depend on the language-specific compile task(s)?  Perhaps depending on lifecycle tasks (e.g `assemble`) is cleaner

`dependsOn(classes)`, but ideally you'd rather use the source set's output as input to the task

`assemble` is too late — it’s an instrumentation task I’m talking about.

<@UDC9Q9RD0> I am actually relying on `sourceSet`’s output currently having the `dependsOn(sourceSet.classesTaskName)`.
Seems like something’s still wrong on my side — the instrumentation task is run too early and classes aren’t written yet:

```...
&gt; Task :plugin:core:classes
&gt; Task :plugin:core:setupInstrumentCode

&gt; Task :plugin:core:instrumentCode FAILED
[ant:instrumentIdeaExtensions] /Users/hsz/Projects/3rd/Perl5-IDEA/plugin/core/src/main/java/com/perl5/lang/perl/idea/configuration/settings/sdk/Perl5SdkPanel.form: Class to bind does not exist: com.perl5.lang.perl.idea.configuration.settings.sdk.Perl5SdkPanel```
But the second run works fine as the `plugin:core:classes` task is already `UP-TO-DATE`:
```...
&gt; Task :plugin:core:classes UP-TO-DATE
&gt; Task :plugin:core:setupInstrumentCode
&gt; Task :plugin:core:instrumentCode
&gt; Task :plugin:core:classpathIndexCleanup

BUILD SUCCESSFUL in 1s```

Note that by "use the source set's output" I rather meant something like `classesToProcess.from(fileTree(sourceSet.output.classesDirs))` and not using `dependsOn` at all.
But using `dependsOn(source.SetclassesTaskName)` should work too. I would print the inputs and whether they exist or not at the start of the task (possibly in a `doFirst`) to try to debug this.

Ok, all classes were available for the task, but then ant taks was spin up and missed them. Anyways, thanks to your latest comment I went into the proper direction. Thanks! :slightly_smiling_face:

Is it possible to declare an artifact as being built by a custom task, but it's files are not its outputs?

Real example: I have a task that runs `npm install` and I need to declare `node_modules/x/**/*.css` as artifact. To avoid massive performance issues with `npm install` declaring `node_modules` as outputs, I implemented something smarter.

The only way I can make it work is by creating a task that depends on `npmInstall` task and copies `node_modules/x/**/*.css` to an intermediate dir. Is it possible to avoid this copy?

<https://docs.gradle.org/current/userguide/declaring_dependencies.html#sec:resolvable-consumable-configs>

Memory settings influences a lot of garbage collection if it is too little. And allocation if it is too much. In the gradle report you should see percentage of the garbage collection and gradle team has recommendation about appropriate threshold for it. I'm not sure if there is measurements about allocation to detect 'a lot of memory' given. My algorithm was to start with small memory setting and increase it gradually to finally reach the enough level.

This usually means the Android plugin is not applied

Check your plugins block, you should have something like this:
```plugins {
  id("com.android.application") // or "com.android.library"
}```

If you have it, then it's something else. It's pretty hard to tell from just that screenshot. Paste your whole file to <https://gist.github.com/> or somewhere else and you might get more help.

Also consider posting to <#CJYS1DAP5|> which will be a better channel for this question

The error means that you messed up the syntax somewhere within the `android { ... }` block. My recommendation is to switch to the Kotlin DSL. You immediately get type-safe build scripts, helpful error messages opposed to what you showed, and an amazingly better IDE support.

If you want to stay on Groovy DSL and get such an error, you either need to just see the error, or you need to comment out all content of that block and comment out again in bit by bit to see where the messed up syntax is

Changing the name of the module to `auth:auth-event-core` seems to fix this for me, but I’d rather avoid having to do that if `TYPESAFE_PROJECT_ACCESSORS` can actually handle this situation but I am hitting some different issue.

Reading the <https://docs.gradle.org/7.0/userguide/declaring_dependencies.html#sec:type-safe-project-accessors|docs> don’t seem to mention any such limitations, but I guess I must’ve missed something?

I know I may not be helping you solve your problem exactly, but I can show you how I’ve done it and it worked for me.

<https://github.com/HedvigInsurance/android/blob/565af1d422921c60940ea9bf45ec7feace63b0b9/build-logic/convention/src/main/kotlin/com/hedvig/android/AndroidCompose.kt#L12-L37|This> is where you’d put all of this, where we set the BOM but of course you can use what you want.
And I get the `LibrariesForLibs` object by doing the&lt;LibrariesForLibs&gt;() by using this workaround <https://github.com/gradle/gradle/issues/15383#issuecomment-779893192>.

In our project, this is defined <https://github.com/HedvigInsurance/android/blob/bc378c995d500e7745848b433e6aa3173e6d3a3f/build-logic/convention/build.gradle.kts#L17-L19|here>. And the <https://github.com/HedvigInsurance/android/blob/ce396d51a817a5d620b5762e627e9fccb9a4ef64/build-logic/convention/src/main/kotlin/ApplicationComposeConventionPlugin.kt#L7-L15|convention plugin> applying this setup is simply calling the aforementioned configureAndroidCompose function.

This has been the best solution for us, as we get full type-safety and autocompletion in there to add the libraries we want using libs.androidx… and so on

yes you can publish to artifactory using just the maven publish plugin

Thanks! Do you know what the url would be formated like when there are multiple repos? Ex artifactory.&lt;host&gt;.com/gradle/project ?

and if its hosted artifactory vs jfrog cloud

We use publish to artifactory and avoid the jfrog artifactory gradle plugin as it hasn’t seen any gradle configuration cache fixes in years

Thanks both! I was able to perform an upload. Much simpler with the maven publish than the artifactory plugin.

`./myprojectfolder/gradlew --project-dir=./myprojectfolder myTaskName` (or `-p` for short)

it defaults to the current working directory

What part of the build is making the request?

log.txt

Looks like configuration.  See attached log from the build.

the ear plugin itself doesn't pull in any external resources, <https://github.com/gradle/gradle/blob/v4.10.3/subprojects/ear/src/main/java/org/gradle/plugins/ear/EarPlugin.java>

But what is making gradle reach out to the CDN on port 80 and is there a way to prevent it from doing that?

maybe a buildscript repository? hard to say without seeing more of your configuration

gradle.tar.gz

I packaged up our pretty complex gradle configuration in the attached.  The key files are the top level build.gradle, settings.gradle and the product/ear/ear.gradle.

there is a buildscript in the top level build.gradle

stubbing it out to the best of my ability and running through a sniffing proxy, configuring that doesn't result in any insecure HTTP fetches for me

perhaps your maven server is redirecting some assets to other HTTP URLs

Also, in your posted log you do not show the request that is made that should be logged on `--info` or possibly `--debug` and a `--stacktrace` would maybe also be helpful to see where exactly the request is coming from.

Btw. be aware that you just published passwords

I tried the various info debug stacktrace and scan options but none yielded any additional info

Are you sure there is no additional info?
Sometimes, you are just not seeing it, but people with more experience reading Gradle logs might see additional information.
Especially the `--stacktrace` output *must* provide additional helpful information, as in your shown output there is no information at all where the issue comes from.

fullLog.txt

Thanks for being so helpful Vampire.  Attaching a full log with --debug and --stacktrace

There, all necessary info is in the stacktrace. :slightly_smiling_face:
While Gradle tries to parse `product/ear/src/main/application/META-INF/application.xml` this exception happens.
So it should be something in your descriptor that references that URL that is accessed.

oh excellent.  One of my colleagues just hypothesized the same thing when he looked at it!  You the man vampire!

Was the XML parser loading a DTD over HTTP or something?

Running in `--offline` mode was how I found this vulnerability in Checkstyle:
<https://nvd.nist.gov/vuln/detail/CVE-2019-9658>

this did indeed prove to be the solution.  Thanks so much folks!

It can but IIRC you won't have type-safe accessors, sor `"integrationTestImplementation"(libs.kluent)`.
I, for one, prefer moving my `testImplementation` to the `test` suite; YMMV.

To get type-safe accessors automatically I think you would need to move the definition of the test suite into a plugin that you then apply using the `plugins { ... }` block.

I think then you should get the accessors, but personally, I'm totally with <@UDC9Q9RD0>

Can you elaborate on this ? How exactly `testImplementation` cna be moved to test suite?

You already have `val test by getting...`.
Add to the closure a `dependencies` block like for the integ tests

Also, you don't need to depend on jupiter engine either way, as you already say that you use jupiter in the test suite, that already adds the dependency

_(which is one thing I really dislike about test suites, as I think it doesn't play right with version catalogs)_

It does, you can give that method a version and that version can come from a version catalog.

• It takes a `String` or `Provider&lt;String&gt;` so you can't just pass `libs.versions.junitJupiter`, and this prevents using rich versions
• It means you configure not dependencies but just a version, making the versions catalog heterogeneous
• This also prevents using forks with different GAV
I think what I dislike the most actually is that `useJUnitJupiter()` is the default for all new test suite besides `test`; I thought we all agreed that adding implicit dependencies was a smell? And if I have to explicitly call `useJUnitJupiter()` or whatever for the `test` suite, why is it different for other suites? (I know `test` is for backwards compatibility; I'm questioning why it was done differently for non-default suites)

&gt;  It takes a `String` or `Provider&lt;String&gt;` so you can't just pass `libs.versions.junitJupiter`,
... why not?
`libs.versions.junitJupiter` *is* a `Provider&lt;String&gt;`.
&gt; and this prevents using rich versions
Well, partly.
`libs.versions....` supports rich versions to a certain degree.
But indeed not fully, yeah.
If you need the full rich version support, you can still declare the dependency manually.

&gt; It means you configure not dependencies but just a version, making the versions catalog heterogeneous
I don't agree.
The version catalog even has in the name that it declares versions.
Indeed it is meant to declare versions, library coordinates, plugins, and bundles.
And using either of them is fine.
You (well I) for example also declare the Java version to use or the JaCoCo version to use which I then use for the JVM Toolchain configuration or the JaCoCo `toolVersion` property.

&gt; This also prevents using forks with different GAV
Well, not prevents, you can still add the fork as dependency and then use capability conflict resolution to select the fork.
Yes, this is not too convenient, but for the benefit of more convenience in the 90 % case where the standard coordinates are used,
while still providing the flexibility to use what you want.

&gt; I think what I dislike the most actually is that `useJUnitJupiter()` is the default for all new test suite besides `test`;
Why?
While I prefer Spock for basically everything as it makes testing fun again,
Jupiter is probably the most widespread one currently and thus a good choice for a conventional default.
Remember, Gradle is about convention over configuration while providing the flexibility to configure whatever you like.
Jupiter is just the convention and you can anytime select a different one via configuration by using a `use...` method.

&gt; I thought we all agreed that adding implicit dependencies was a smell?
I don't think we agreed on that anywhere or even discussed it anywhere.
Implicit dependencies that are not opitional, I would probably agree.
But default dependencies as convention that you can override are imho perfectly fine
and used in several places, like the JaCoCo dependency, the Checkstyle dependency, the PMD dependency, .....

&gt; And if I have to explicitly call `useJUnitJupiter()` or whatever for the `test` suite, why is it different for other suites? (I know `test` is for backwards compatibility; I'm questioning why it was done differently for non-default suites)
Probably because JUnit 4 is old and stinky, and using it as convention for the new stuff just because the one `test` one needs to stick with it for backwards compatibility would be more consistent, but highly questionable.

&gt; ... why not?
&gt; `libs.versions.junitJupiter` *is* a `Provider&lt;String&gt;`.
Ah yes, was used to using the non-type-safe API where `findVersion` returns an `Optional&lt;VersionConstraint&gt;`.

Everything else (declaring dependencies in addition to that, adding capability conflict or whatever) is just a workaround that wouldn't be needed if Gradle didn't insist in adding dependencies itself without the user asking for it and without any way to opt out.

YMMV

(oh wow, I only now discover that Gradle automatically adds some flavor of JUnit 4 if you don't explicitly call a `useSemeTestFramework()` on the `Test` task :nauseated_face:)

I totally agree that a `useNone()` and especially a `useJUnitPlatform()` are missing.

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

I guess <https://github.com/gradle/gradle/issues/847> is somewhat related.

You can change the names of the JARs using `archivesBaseName` (<https://docs.gradle.org/current/dsl/org.gradle.api.Project.html#org.gradle.api.Project:archivesBaseName>) or `base.archivesName` (<https://docs.gradle.org/current/dsl/org.gradle.api.plugins.BasePluginExtension.html#org.gradle.api.plugins.BasePluginExtension:archivesName>) in the projects.

```base {
  archivesName.set(parent.name)
}```
to use the parent project's name

I would always define names in the settings file (although the API is not that elegant yet). It's the way of least confusion. And the way that fits the idea of a clear _component identity_ in Gradle's model when it comes to dependency management.

You then have a _uniques simple name_ for each project, that is used for the Jar names and would also be used in the coordinates if you should publish the project or address it from another build in a composite build context.

You could 'automate' the name assigning (e.g. always put the parent folder name as prefix) in the settings file by looping through your folders and doing the "include" and "projectDir" based on the project path. (Maybe someday this will be followed up on <https://github.com/gradle/gradle/issues/14561> and a cleaner API for the settings file emerges)

And probably Gradle should move towards eventually deprecate the "nested" project idea. Having two ways to identify projects...

*GA-Coordinates* vs *project path*

...leads to many confusions, issues (like #847) and headaches for plugin authors doing plugins in the dependency management area.

Besides that I personally try to avoid depending on tasks by `String`, it will only depend on the task of the project you are configuring there.

You can easily verify by doing `./gradlew --dry-run :whatever:jacocoTestReport` to see which tasks would get executed