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

Gradle Community

Not really. What is there is pretty minimal: <https://docs.gradle.org/current/userguide/variant_attributes.html#sec:abm_disambiguation_rules>

Disambiguation rules do not really _interact_ with each other.
What happens is that once Gradle has filtered out _incompatible_ variants, it looks at the remaining ones and filters them through disambiguation rules _independently_, looking for an intersection.

In your case, the api vs. runtime rule will prefer `apiElements`. But the packaging rule (fat jar vs. external deps) will prefer `unshadedRuntimeElements`. And so there is no intersection between the rules.
And this results in a failure.

However changes are being made around that area, and attributes will have a hierarchy. This should allow such a case to properly resolve, because usage will be looked at first over bundling.

<@UAFD2T2QG> Can you share more on this?

(and you left a project name in there Chris :wink: )

That sounds great and makes sense. I’ve got around this for now by creating a custom `LibraryElements` attribute value for the `unshadedRuntimeElements`  configuration and then defining a new `AttributeCompatibilityRule` to define how this value interacts with the existing values.

I've had a similar situation but was looking for a way to tag the scans rather than fail the builds.  I was unable to find any solution for this when I went looking. :confused:  This question might be better posed in <#CFW1EQHNE|>, also.

Gradle Enterprise actually track that event and displays it in the performance/buildCache screen, so it should be fairly simple for them to generate a tag.
Probably a nice addition for the <https://github.com/gradle/common-custom-user-data-gradle-plugin|custom user data plugin>

I cannot follow in which way you think this is Gradle related, except that a Gradle task is triggered.
The error tells you to speak to the maintainers of `react-native-fetch-blob`.

We have a gradle task running in our azure devops pipeline. The last time the task was successfull was Jan 23 2022. After that its been failing with same error.

Sure, but as I said, the error had nothing to do with Gradle. That you happen to execute the process with Gradle is imho irrelevant for your error. You use, or something you use uses, `react-native-fetch-blob` which uses `react-native-community/cli` with a version range and that dependency is not to be used anymore.

AFAIK no - they depend on project, and build services are independent of projects

Injecting `ProjectLayout` for the former and `ArchiveOperations` for the latter should probably work

Ah, right about the `ProjectLayout` <@U019L3NM4PK>, but `ArchiveOperations` should work.

thanks.  Gradle kaks on injecting ProjectLayout, rightfully so as it’s project-specific.  Haven’t tried ArchiveOperations yet.

And `ObjectFactory` for creating a file tree

<https://docs.gradle.org/current/userguide/userguide_single.html#services_for_injection>

&gt; Out of the above, `ProjectLayout` and `WorkerExecutor` services are only available for injection in project plugins.


both ObjectFactory and ArchiveOperations inject cleanly.  thanks folks.

However, I’m getting this

```hello ➤ ./gradlew hello                                                                                                                                                                       

&gt; Configure project :
Finding dep: this should be overridden
Finding dep: this should be overridden

&gt; Task :hello
hey, I did it```

my goal is to be able to have an extension to be able to set some values that I can pass along to the build files in my project

trick is to avoid calling `project.rootProject.extra["message"] = extension.message.get()`- let the framework (Gradle internals) do that when needed, or do it yourself inside a task at execution time (as the latter `get()` call)

The issue is I have a task that is setting a bunch of properties in the configuration phase

that’s ok, so long as it avoid calling .get() on the extension - it can grab extension.message and use that to set other properties, flowing the lazy Property/Provider through.

Something like this, where privateRepositories is an extension property passed to a task
```withType&lt;GoTask&gt;().configureEach {
privateRepositories.set(extension.privateRepositories)
}```

nice, it totally worked.

i can just pass `extension.message.get()`  to my task.

thanks again!

Sounds like this issue: <https://github.com/Kotlin/dokka/issues/1833>

Could be related.

I've created a new issue for this with more details: <https://github.com/Kotlin/dokka/issues/2424>

If the docker task you want to configure doesn't support inputs...I would just do the operation you are doing in your task in a provider and use it.

You are just pushing your luck by configuring extras in a tasks that are read by an extension

If the docker tasks has the inputs, and parsing the files is expensive you can use your task, write some file with the outputs and use those files as inputs (creating a dependency between the tasks)

This is an <#CJYS1DAP5|> specific question

It seems like all variants are always configured no matter what (I haven't look if that supposed to be like that)

you’re right this is android’s specific.

but from a gradle’s point of view. `configureEach` should work the way I’m expecting to based on my description?

I was trying to find applicationVariants type

what that tells you is that the Android Gradle Plugin eagerly configures all its variants. nothing Gradle itself can do about that

Reading the docs I don't see the difference

I expected all to be "worst" (for example only consuming elements added before it's invoked) but it seems it's not:

&gt; Executes the given action against all objects in this collection, and any objects subsequently added to this collection.

`.all` is eager - it runs immediately on existing objects, as well as being configuring future objects as soon as they are added

whereas `.configureEach` is lazy - it runs when each object is configured, instead of as soon as it is registered

<https://docs.gradle.org/current/userguide/task_configuration_avoidance.html#sec:old_vs_new_configuration_api_overview>
&gt; Instead of: `DomainObjectCollection.all(org.gradle.api.Action)`
&gt; Use: `DomainObjectCollection.configureEach(org.gradle.api.Action)`

That's what I expected...but then..maybe the docs need to mention it. :thinking_face:

it could probably be stated more clearly, but <https://docs.gradle.org/current/javadoc/org/gradle/api/DomainObjectCollection.html>
&gt; void all(Action&lt;? super T&gt; action)
&gt; Executes the given closure against all objects in this collection, and any objects subsequently added to this collection.
&gt; 
&gt; void configureEach​(Action&lt;? super T&gt; action)
&gt; Configures each element in this collection using the given action, as each element is required.
already implies that configureEach is lazier than all

Took me a while to find this. It would be nice if there was something that would steer us towards the correct API to use. Maybe soft deprecating the existing eager APIs and providing a new one with clearer naming. 

<https://gradle-community.slack.com/archives/CAHSN3LDN/p1649442110194519?thread_ts=1649440291.522169&amp;cid=CAHSN3LDN|https://gradle-community.slack.com/archives/CAHSN3LDN/p1649442110194519?thread_ts=1649440291.522169&amp;cid=CAHSN3LDN>

<https://github.com/gradle/gradle/issues/16344|https://github.com/gradle/gradle/issues/16344>

Well now I feel stupid considering I already upvoted that issue :laughing:

Maybe with `--rerun-tasks` Gradle would skip that?

On a task level there is `Task.doNotTrackState()`  or `@UntrackedTask` from 7.3, check <https://docs.gradle.org/7.3/userguide/more_about_tasks.html#sec:untracked_external_tool|release notes>. I don’t think there is anything on a build level. But you can try set `doNotTrackState()`  for your npm tasks if that could solve your issue.

Thanks Anze. I think I might file a feature request. It makes sense. On my PC it takes an additional 25 seconds of build from the moment npm install finishes, to the actuall end of build in Gradle. A bit crazy.

Feel free to open an issue.
Does `doNoTrackState()` solve the issue for npm task though?

<@U02DF9JDXJM> we're on 7.1 unfortunately and it's not easy to upgrade. I actually filed another issue related to this.

For now I think I'll end up conditionally defining an npm install tasks depending whether we are on build system, or not

out of curiosity, what are the limitations you're talking about?

sigh, :smile: I kinda hoped I would get the answer first before I will have to explain - but this was expected

we would like to organize our scripts by using Groovy `apply-from` with scripts, projects contains at least 30+ modules and is growing, we would like to share as much code as possible, the way you work with `apply-from` is to create base script file and then then extend is with more specialized ones

the only way I found to to mimic that in KTS is by using functions defined in `buildSrc` something like that

```private fun Project.moduleJvm() {
    moduleBase()

    // Uniform way of configuring Kotlin tasks in all Kotlin modules
    tasks.withType&lt;KotlinJvmCompile&gt;().configureEach {
        kotlinOptions.jvmTarget = KotlinConfig.jvmTarget
    }
}```
Where functions are calling one another, from more specialized one to basic one

Maybe "limitation" is not a best word, but this approach makes things very cumbersome with comparison to Groovy approach with apply-from.

More or less that's it

I wrote very simple plugins and then you can have a hierarchy when you have a base plugin and more specialized ones

the more specific plugin applies the base plugin

That's why I asked the question, because maybe Kotlin is not the source of your worries :wink:

whether it's Groovy or Kotlin DSL, plugins are the intended solution.

And if you use precompiled script plugins, you can even write them almost like normal build scripts.

Well, I don't see why not, I haven't seen this approach suggested but still, I used `apply-from` approach in previous company and main benefit of that was syntax, teams understood it right away and plugins were not required

- but I will take a look at plugins

As I said, if you use precompiled script plugins, the syntax is basically identical and it is the recommended approach.
Normal script plugins  (thing you use with `apply from:` are long discouraged already in favor of convention plugins which are most often implemented as precompiled script plugins.

For Groovy vs Kotlin: there are no plans at all to drop Groovy.
For sharing build logic additional to what other said you might want to check this sample: <https://docs.gradle.org/current/samples/sample_convention_plugins.html>. It codes as a build script, it works as a plugin.

I would like to be a massive reorganization of Gradle in 8.0-10.0 by deprecating/removing legacy patterns and setting as default the new patterns

multiple of them would need drop the legacy implementation and replace with the new one using the same APIs but being lazy, and that is hard to do without a lot of breaking changes 

&gt; apply from will be deprecated?
Not that I'm aware of.
I said it is discouraged, not deprecated.

`apply from` does work with Kotlin DSL same as Groovy, you just get zero generated type-safe accessors. whether you stick with Groovy or Kotlin you should change them to plugins. as Björn mentions, it is easy to just copy-them into precompiled script plugins. and then you get generated type-safe accessors and all that.

This is a good example that I was able to reproduce myself locally <https://github.com/square/anvil/blob/main/settings.gradle#L17-L21>

it replaces the <https://github.com/square/anvil/blob/main/dependencies.gradle#L42|plugin definition here> with the module in the <https://github.com/square/anvil/tree/main/gradle-plugin|project>

thank you
I actually made it work the same way
However, I'm confused, if we intent to substitute plugin, why don't we make so from `pluginManagement {}` block?

The way we do it - from flat settings - leads to just replace dependency in some `dependencies {}` block which is then used to locate classes used in implementation, or plugins applied in precompiled-scripts used when we make convention plugins.

I believe, it would be more natural if we could substitute *plugin*, not a *dependency* (which is then supposed to provide that plugin), as we normally do in `pluginManagement -&gt; resolutionStrategy {}` block, as I shown in my sample. In other words, I'd like not to replace dependency given its *group:artifact*, but plugin given it's *id* and applied in `plugins {}` block. I'd like it to work for any `plugins {}` block in the composite project.

Because, if I use the approach replacing dependency with it's *group:artifact*, that means I HAVE TO make convention-plugin wrapper, that would wrap `plugins {}` block with the plugin I'd like to substitute. And hence, I have to apply that convention-plugin everywhere instead of appliance raw plugin I want to substitute explicitly in each subproject in `plugins {}` block.

Does it make sense?

btw, `dependencySubstitution {}` block is not available for `includeBuild()` from `pluginManagement`.  Ok, but when I tried to do the same with `pluginManagement -&gt; resolutionStrategy {}`, I failed to substitute - it was always using original 3rd-party `org.sonarqube` plugin instead of those provided from included-build.

You should neither need a custom name, nor a manual resolution rule, nor a manual dependency substitution.
Just `includeBuild` the build and it should work usually.
Having the `includeBuild` outside the `pluginManagement` comes from not so far times where only the outer one existed.
But for plugins it is preferable and for settings plugins even required to do it inside the `pluginManagement` block.

I also tried it in a play project and it works perfectly fine for the SQ Gradle scanner plugin.
If it does not for you, please show an MCVE where it does not work.

it worked for me, when I put a single line
```includeBuild("/Users/mymac/Soft/OPENSOURCE/sonar-scanner-gradle")```
outside any block in my `settings.gradle`.

my convention plugin was declaring dependency on
```implementation org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:3.3```
but after adding `includeBuild()`, for it to be substituted I had to change this declaration to
```implementation org.sonarsource.scanner.gradle:sonarqube-gradle-plugin```
after that, my convention plugin had the local changes I made in my local version of `org.sonarqube` plugin.

Ah, yes, in that case it is used as a dependency, not as plugin, so you need it outside the plugin management block. But you shouldn't need to change the declaration. The included build should always win.

so, if i'm going to just use `org.sonarqube` plugin applied from `plugins {}` block in some of my subprojects, w/o having any convention plugins (not using as a dependency), then I'd just need to add
```includeBuild("/Users/mymac/Soft/OPENSOURCE/sonar-scanner-gradle")```
inside `pluginManagement {}` block and that's it?

And it will silently substitute every appliance of `org.sonarqube` with my local version of it without any changes in any build scripts required?

What's the problem with having that base convention plugin that you then apply in your more specific plugins?

Right now, I would say, getting Android plugin DSL dependency(ies) injected correctly

I'm trying to use `id("com.android.base")` in hope that maybe it will create proper `android` extension in base convention plugin and will provide things I need

Bit of a struggle against Android plugin, because I would like to configure extension that is not yet there, and since none of android plugins is applied in base convention plugin I'm looking for a way to delay it a bit, beside properly injecting missing classes

I'm not really familiar with Android dev.
But afair the android base plugin does not register an extension, but the different android plugins register different extensions under the same name.
So it might not be possible like you try.
Maybe you should just have some helper methods that you call from your more specific plugins that contain the common logic.

yeah, working on few ideas ot once, this is why I like `apply-from` it might not have typesafe accessors, but it allowed me to do those things without any headache, but still trying convention plugins

Everything you can do with a script plugin (apply from) you can do with a normal binary plugin or a precompiled script plugin too.
Not sure why you think a script plugin gives you any advantage.

I'm not saying I can't, I just simply didn't needed

&gt; ... some helper methods that you call from your more specific plugins that contain the common logic.
I'm not sure if advantage is the word I would use, but for sure it was easier to accomplish, more straightforward  - I could probably create simple public project to show differences, I worked with script plugin now I'm working with convention plugin, I just see the difference and the fact that it's 2nd day I'm trying to figure out how to sew it all together in order to achieve expected result, but like I said, not giving up on  convention plugin

Maybe it's more strange AGP things vs. normal Gradle usage. :smile:

:thinking_face: actually ... yes :smile: AGP, tough love

I never liked that hint to get help from Gradle tbh.
That hint is basically just useful for people actually writing the build and having problems.
Not really for people executing a build and having problems with that.

Your build is executing `aidl.exe` with some arguments and the call does not complete successfully. This has nothing at all to do with Gradle. Maybe you get more information if you execute with `-i` to maybe get the actuall error displayed, as what you showed does not show the actual error. Maybe it is also available in that log file the error message mentions. If all does not help, maybe execute the aidl command with the shown arguments manually to maybe see what the actual error is.

Okay, yes, the issue had nothing to do with Gradle, I managed to fix it without touching anything related to Gradle :sweat_smile:
Thank you for your help, I'm sorry for taking your time :pray:

My advice would be to ask the maintainers of that plugin as you have problems with their plugin, not with Gradle.

You can create a configuration, add one dependency to it, and then look at its files and their size.
Repeat for the other library, and compare.

although that might not be the actual size increase, because if it's sharing libraries you're already depending on, then that's effectively free

I would simply try adding each the library then measuring your project's build size

&gt; although that might not be the actual size increase, because if it's sharing libraries you're already depending on, then that's effectively free
ok I can run it in a new project where I add only the dependency which I wanna measure.
&gt; I would simply try adding each the library then measuring your project's build size
Good alternative: with build size you mean the size of the apk?

if you're talking about an Android app, then the size of the .aab or .apk, yes. the size of the JARs is not very representative because your release build will get proguarded

release apk, usually yes. debug apk, usually not

Thanks I will try this :slightly_smiling_face:

note that you'll actually have to make use of the library otherwise proguard will see all of it as unused and drop it

yes, but then the sizes you get will not be similar to the sizes you'll get when you actually use the library, so it's not very useful

I'm just interested in the absolute size of the lib and its deps, so I guess it's negligible

why do you care about that? shouldn't what matter be the size of the part of the lib that you actually need when proguard retains it?

hmmm I know what you mean, makes sense, thanks for the insight. But then I would have to write code for every library, that's not worth the time

Well, then you probably should not choose by size :slightly_smiling_face:

It’s likely that both IntelliJ and Gradle need to be configured to use a proxy when on the VPN

yea but how, I figured it was inputing hosts and ports to the proxy, and those I’ve no clue what they are

If you have usual http proxy you can try to set proxy host/port/auth in IDEA's `File | Settings | Appearance &amp; Behavior | System Settings | HTTP Proxy`.

If it's not enough you'll likely have to set gradle proxy like described here: <https://docs.gradle.org/current/userguide/build_environment.html#sec:accessing_the_web_via_a_proxy>. Gradle wrapper should use same system properties above. Maybe ide sets these parameters for you but you'll still need them to run gradle (and wrapper) from terminal.

Another way is to configure vpn to be used only for internal resources (like for certain subnets and domains). It's system dependent but allows you to avoid sharing all your activity with employer ,)

Some notes in unspecific order:

• iterates over each subproject and applies `jacoco` plugin for each subproject in `suproject.afterEvaluate {}` block
Actually two reasons to strongly consider not using that plugin imho.  The first half means cross-project configuration which introduces project coupling and does not work well with more advanced Gradle optimizations like the upcoming configuration cache, the second half like any `afterEvaluate` most probably mainly introduces race conditions and timing problems as it for example does not see changes made in later `afterEvaluate` blocks. Most usages of `afterEvaluate` are a code smell and should be changed to something else.

• Actually what the SonarQube plugin does also does not sound much cleaner and should for example be replaced by the JaCoCo aggregation plugin to collect all JaCoCo reports instead of doing unsafe cross-project publication as detailed in the Userguide.
But if you want to follow the bad practice of the plugin, just use the same tactic to depend on, using `withType&lt;JacocoReport&gt;()` as that is lazy and will also catch all tasks of that type added later. Of course your control "println" would still print an empty list, as at the time you evaluate it, the tasks are not yet there.
And you also must not eagerly resolve the provider using `stream` and `toList` or you also destroy the laziness, but instead depend on the actual providers.
If you also need to check the `skipProject` property, you probably have to further follow the bad practice and do the configuration in an `afterEvaluate` or you are not seeing the `skipProejct` values that were set as they are not set yet.

Thank you for quick reply.
So, what I have in root-project build.gradle.kts, can be reduced to:

```tasks.withType&lt;SonarQubeTask&gt;().configureEach {
    val jacocoTasks = project.subprojects.stream()
        .map { p-&gt;
            p.tasks.withType&lt;JacocoReport&gt;()
        }
        .collect(Collectors.toList())

    dependsOn(jacocoTasks)
}``````
Regardless of bad practices this snippet follows, as well as both 3rd-party plugins (cross-config, non-laziness, etc), my main concern is - 

how to make 

some task A which is supposed to be invoked from the root project (`SonarQubeTask`)

to depend on all tasks of a particular type (`JacocoReport`) from every subproject (given that their names might be dynamic)?

——
Also, what could be “the best practices” approach to accomplish that? With configuration avoidance/caching in mind.

I guess for the "best practice" those plugins you use need to be adapted first.
Doesn't that snippet work for what you wanted?

Regarding best practices, actually any `dependsOn` you write is wrong.
Whenever you do a manual `dependsOn` (except for lifecycle tasks like `check` or `build` that are designed to just trigger some other tasks),
it is a sign of something not being idiomatic.
Usually some task A does not depend on some other task B being executed.
Usually some task A needs the output of some other task B as input.
So task A should use the corresponding output property of task B as value for its input property and thus get the task dependency automatically implied.

But this is only to be done within one project.
Cross-project you then have configurations or variants to share outputs of tasks with other tasks.
For more information on how to do that properly, you can read <https://docs.gradle.org/current/userguide/cross_project_publications.html>

And especially for aggregating JaCoCo results cross-project there is even <https://docs.gradle.org/current/userguide/jacoco_report_aggregation_plugin.html>.
It adds a task for an aggregated JaCoCo report, but it also provides the JaCoCo result files needed for the report and thus needed for SonarQube in an added configuration
like described in above mentioned cross project publication section.

Thank you for sharing. I will plan to migrate to Jacoco Aggregation plugin. However, it’s not quite feasible to do quickly.

Btw, there is no “compliant” SonarQube plugin for now, so I have to stick with that not compliant with the best practices.

And after all, my snippet doesn’t work, and running just `,/gradlew sonarqube` from the root project still requires all jacoco XML reports to be generated in advance, so I have to run:

`./gradlew jacocoTestReport jacocoTestReport&lt;BuildVariant&gt; sonarqube`

(Which relies on `sonarqube.mustRunAfter(jacocoReport)`).

Do you think it doesn’t work because those 3rd-party plugins (com,vanniktech.android.junit.jacoco, org.sonarqube) are not implemented properly?
So they don’t work correctly when i try to do whatever looks logical, because of internal bad-timing, concurrency and code-smell?

So that means, these plugins prevent me from having what I want to achieve 

This code snippet has eventually solved my issue:
(from root project build.gradle.kts (in my case, from convention plugin applied at root project)
```tasks.withType&lt;SonarQubeTask&gt;().configureEach {
    rootProject.subprojects.forEach { p -&gt;
        dependsOn(p.tasks.withType&lt;JacocoReport&gt;())
    }
}```
now, `./gradlew sonarqube` also involves running all `test&lt;Variant&gt;UnitTest` and `jacocoTestReport&lt;Variant&gt;` tasks first, generation jacoco reporst, so SonarQube could find them. My principle here was to rely strongly on liveness of `withType()` method w/o adding extra complexity that might let that liveness averted.

<@URQ797WRW> what do you think, how compliant with the best practices that code snippet might be? My main concern is whether this code compliant with Configuration Avoidance? Regardless of usage *dependsOn*.

Regarding task configuration avoidance it should be fine.
Regarding best practices, nothing changed from what I said above. :slightly_smiling_face:

Now the issue is - how to make some exclusions for the generic filter `withType&lt;JacocoReport&gt;`? This filter can collect both `jacocoTestReportDebug` and `jacocoTestReportRelease` variants of the task. When I build for release build type, how could I exclude the latter from consideration (ignore it completely)? Basically, I want this code snippet to only work for debug-variants of the tasks (android subprojects), but still collect `jacocoTestReport` (“unscoped”) tasks for pure Java/Kotlin subprijects.

`tasks.withType&lt;JacocoReport&gt;().matching { !it.name.endsWith("Release") }` maybe?
Actually this will again work against task configuration avoidance though, as for `matching` all tasks on the left have to be realized to be given to the predicate.

Otherwise you could enumerate them manually of course.

So, this cannot be solved with configuration avoidance, i guess? Since for android subprojects tasks are generated dynamically. Or we can make this sample with configuration avoidance?

For java/kotlin subprojects, where task names are known in advance, I believe we cannot come up with the example, when we’d need to filter out some tasks based on it’s “property”. So it’d be always using `withType` and hence, with configuration avoidance? Unless we use `matching` for some purpose. 

Is there any use case, where we could use `matching` for whatever reason to filter tasks, but preserving configuration avoidance?

Again, to check the predicate you give to `matching`, the task must be realized, so you cannot have configuration avoidance while using `matching`. That's also the reason you should never do `tasks.matching` if you can avoid it, because it would cause each and every task to be eagerly realized, but always do a `withType` before that at least only tasks of that type are realized due to the `matching`.

As I said, if you want to do it while preserving configuration avoidance, you could for example enumerate the task names manually, using `tasks.named` instead.

There are several of them depending on your workflow. I currently use `nebula.release` (calculates version base on git tags, create new tags etc) with publishing triggered by tag pushed to remote repo.

What I certainly like with this one is versions like `1.2.0-dev.7.uncommitted+quarkus.migration.deadbee`: previous tag was 1.1.x, so incremented minor version by default + `-dev` suffix, `7` is number of commits since that tag, `uncommitted` for dirty repo state (some uncommitted changes present in worktree), `quarkus.migration` produced from feature branch name `quarkus-migration` and last token `deadbee` is last git commit id.

I use the `net.researchgate.release` plugin. I is much like the Maven release process, and afair also was designed to be similar.

It cannot calculate the version from Git history, but it will un-snapshot on release, increase afterwards, commit, tag, push, ...
But I actually greatly dislike calculating version from Git history, at least if it is the sole source of version, because that always requires the Git repository to do a simple build. You cannot for example build from a source ZIP.

I used it before (alongside maven release plugin for other projects). My case is for internal projects with git-first approach so it works for me since I don't need to publish separate source tgz/zip.

I also dislike classic snapshot versions without commit info or similar meta to trace where deployed artifact came from.

So it's matter of preference, I guess.

I ususally generate the commit info and dirty state into a properties file if Git is available, so the info is there, just not in the version number :slightly_smiling_face:

Thank you Grossws and Vampire for your help, i will try both and let you know.

iirc there were some other plugins for using both approaches

<@UJUMPU407> I tried nebula release struck with this error:
* What went wrong:
Execution failed for task ':releaseCheck'.
&gt; Branch OPS-14338 does not match one of the included patterns: [master, HEAD, main, (release(-|/))?\d+(\.\d+)?\.x, v?\d+\.\d+\.\d+]
I tried with this configuration
```nebulaRelease {
    Set&lt;String&gt; releaseBranchPatterns = [/master/, /HEAD/, /OPS-14338/, /main/, /(release(-|\/))?\d+(\.\d+)?\.x/, /v?\d+\.\d+\.\d+/] as Set
  //  addReleaseBranchPattern(releaseBranchPatterns)
}```
It didn't work.

I'm not sure why you want to create tag from issue based branch like that. What release management approach and branching model in git do you use?

Independent of that, you are creating and setting a local variable.
How should that change anything in the plugins configuration?

The readme of that plugin is just very user-unfriendly and misleading

We are using GIT, for versioning, we are using major.minor.patch version model. As of now we have following command in jenkins pipeline for release branches:
```                       mvn build-helper:parse-version versions:set -DnewVersion=\\${parsedVersion.majorVersion}.\\${parsedVersion.minorVersion}.\\${parsedVersion.nextIncrementalVersion} versions:commit```
This will basically bump of version. I am looking something similar, please let me know if you need any details. I declared version in gradle.properties, earlier it was in pom.xml

That is exactly what the researchgate plugin does during the release process, but it can of course also be triggered manually.

Ahh, I missed that `addReleaseBranchPattern` is commented.
<@U02HEBX36Q7>, try plugin that <@URQ797WRW> suggested. It'll likely fit your current model much better.

yes, trying. I commented as it was not working.

It probably was not commented and then complained that the signature is not found when executing the build as the method expects just one `String`

That's one of the major drawbacks with sticking to the Groovy DSL

And one of the major reasons I exclusively use the Kotlin DSL

Much better IDE support and type-safe build scripts

I'm on kotlin dsl myself but it has it's own drawbacks since ide sometimes becomes crazy with it 'cause some cache not invalidated in time

Should have been either
```nebulaRelease {
    releaseBranchPatterns = [/master/, /HEAD/, /OPS-14338/, /main/, /(release(-|\/))?\d+(\.\d+)?\.x/, /v?\d+\.\d+\.\d+/]
}```
or
```nebulaRelease {
    addReleaseBranchPattern(/OPS-14338/)
}```


&gt; I'm on kotlin dsl myself but it has it's own drawbacks since ide sometimes becomes crazy with it 'cause some cache not invalidated in time
I'm on Gradle since its pre-1.0 phase.
The time I lost through Groovy shenenigans that would have saved by Kotlin DSL for me heavily outweighs the problems you sometimes have with Kotlin DSL. :smile:

Yeah but using branch like OPS-14338 would be against underlying idea how to use nebula release. And likely require to redo Jenkins pipeline

This is the test branch i am trying with. We generally use release branches to release new version.

I'm with you on that. The only case where I found groovy dsl useful for me is in init script supporting 6.1-7.x which use api like dependencyResolutionManagement, build services, exclusive content etc in one script to configure private repos to avoid creating multiple feature-dependent classes in-place.

Hi All, one more question, do we have anything similar to this, anywhere did you encounter this?
mvn versions:set-property -Dproperty=r4e-dependencies.version -DnewVersion=[R4E-DEPENDENCIES-VERSION-FROM-DEVELOP]

Basically i would like to update a value defined in gradle.properties using CLI. Do i need to define new task or any plugin available

Is this the version of a dependency you use?
I wouldn't keep that in a properties file, but use the Gradle version catalogs feature.
And if you use that, there are plugins that can check all your dependencies for newer versions like the `gradle-versions` plugin by Ben Manes,
and also extensions that can directly update to those new versions in the TOML file containing the versions.

I am using a version catalog, i define version catalog version in gradle.properties

each time i push new release i would like to update version catalog version as well

Hm, well, I know of none, but I'm pretty sure some plugin out there can do it.
But it should also be a very simple ad-hoc task.

```task setVersion(newVersionCatalogVersion)  {
    Properties props = new Properties()
    props.load(new File('gradle.properties').newDataInputStream())
    props.setProperty('r4eVersionCatalogVersion', newVersionCatalogVersion)
    props.store(propsFile.newWriter(), null)
}```
I tried with above it is giving error saying newVersionCatalogVersion not found in groovy

do i need to say
task setVersion(def newVersionCatalogVersion)  {

You cannot make a task get parameters like that and if if you could, you didn't define a task action, but only configuration code that is executed in the configuration phase.
And as you used eager API even always executed, whether you execute that task or not.
You should read a bit in the manual about how to write tasks first.

Also how can i pass environment variables using gradle command line, it is not working

example: gradle jib -i -DdebianDistribution=dev -Dbuild.number=293 -Djib.httpTimeout=60000

```def debianDistribution = System.getenv("debianDistribution") == null ? "ENV_NOTFOUND" : System.getenv("debianDistribution")
def buildNumber = System.getenv("BUILD_NUMBER") == null ? "NO_BUILDNUM" : System.getenv("BUILD_NUMBER")
println( System.getenv('debianDistribution'))
println(System.getenv('BUILD_NUMBER'))

subprojects {
    // apply plugin: "com.gorylenko.gradle-git-properties"
    apply plugin: "com.google.cloud.tools.jib"
    if (it.name.contains('-thrift')) {
        apply plugin: "org.jruyi.thrift"
    } else {
        apply plugin: "io.spring.dependency-management"
        apply plugin: "org.springframework.boot"
        apply plugin: "org.sonarqube"
    }
    jib {
        from {
            image = baseImage
        }
        to {
            image = "<http://gcr.io/rep-ops/${project.name}:${version}-|gcr.io/rep-ops/${project.name}:${version}->"+debianDistribution+"-"+buildNumber
            credHelper = 'gcr'
            tags = ['latest', project.version]
        }
        container {
            entrypoint = [
                    'sh', '-c', '/entrypoint.sh'
            ]
            ports = ['8081', '8080']
            environment = [
                    "SPRING_OUTPUT_ANSI_ENABLED": "ALWAYS",
                    "MAIN_CLASS"                : "test",
                    "DEBIAN_JAVA_OPTS"          : "test"
            ]
            mainClass = "test"
            creationTime = "USE_CURRENT_TIMESTAMP"
        }
        extraDirectories {
            paths = "$projectDir/jib"
            permissions = [
                '/entrypoint.sh': '755'
            ]
        }
        allowInsecureRegistries = false
    }
}```


You are setting Java system properties and are reading environment variables, those have nothing in common.
And actually you should probably better user Gradle properties.

Besides that, just in case you are not aware.
Using `subprojects { ... }` introduces project coupling and is highly discouraged in favor of using convention plugins.
And `apply plugin` is legacy way to apply a plugin which should not be used in favor of `plugins { ... }` DSL.

Which gradle version?
Maybe try with --buildscan as that's what helped me debug something similar which ended up being a plugin issue.

though i've seen this on previous versions as well

so I was using <http://warp.dev|warp.dev>, switching back to regular macos Terminal solved my problem...

Please don't cross-post questions to multiple channels.
Pick one that is appropriate and stay with that.
Channel topics help to choose, actually this channel would have been the right one.
Cross-posting messages wastes the time of erveryone reading your message mutliple times and splits discussions.

Then read channel topics please, that's what they are for.
And at most post in one channel and post a link in other channels if you really need to use multiple channels

• Observation 1 is the consequence of the Jacoco plugin configuring _all_ `Test` tasks of the project for producing coverage data.
• Observation 2 is the consequence of the Jacoco plugin only configuring a report task for the default `test` task.
So your report configuration on the extension only applies to that report.
• I do not know about observation 3 …
<@UAH55SJ2D> Could you take a look at the above?

Also regarding Observation 1, keep in mind that the `.exec` file is the *input* for the `JacocoReport` task, it is an output of the `Test` task that is configured with the JaCoCo agent to produce that file.

Regarding Observation 3,
yes, the directory exists, but the message says it tries to read it as *file* which results in an access denied exception.
You call the `executionData` method with a `TaskProvider` but the task is not capable of processing that properly. It only accepts `TaskCollection`, `Task`, and `Object`. So in your case the `Object` variant is used which is resolved as if you give it to `Project.files` and thus it's defined outputs are used, which is the test results directory, not the Jacoco data file. As the `TaskCollection` variant would anyway eagerly resolve all tasks and thus prevent task configuration avoidance, you can also directly use eager API and use the `Task` variant. So for example `executionData tasks.integrationTest` should work fine, as the JaCoCo plugin is simply not yet adapted to lazy APIs properly.

Here an according issue: <https://github.com/gradle/gradle/issues/13346>

Thanks for the quick repliies!

Yeah, I'd always thought _build/jacoco/*.exec_ was generated by the _jacoco_ plugin.

<@URQ797WRW> passing the `Task` rather than `TaskProvider` has fixed the issue.

Thanks, <@URQ797WRW>, for the great explanation!  That linked issue is one we should consider as past of continuing work on the Provider APIs, which should become more of a focus for the team soon.

<@U02BBCEP65V> What the reason is for aggregating execution data across multiple test suites with different `TestSuiteType`s?  During development, we were wondering if there would be a need to add an easy way to configure a single report to aggregate either 1) all test suites of any type within a single project or 2) all test suites of any type across all project dependencies present in the `jacocoAggregation` configuration.  The initial version of the aggregation feature did not offer this, but we are currently discussing how to expand and improve Test Suites and related features.

I usually prefer to have separate coverage for unit tests and integ tests, as I strive to have full coverage with unit tests and then with integ tests separately around 70 - 80 % in projects where I care about tests.

But I also know the position that it is sufficient if any test type tests a code part. For that a combined report over all test types is helpful.

<@U02AA235DGC> I am sending coverage data to Sonaqube via `sonaqube` plugin. In the SonaQube UI there is a single _code coverage_ statistic. Since I have a single-module Gradle project with unit + integration tests, this is why I wanted to combine the execution data into a single XML report to send to SonaQube. Let me know if there are any other approaches.

You can also give it multiple paths to multiple files

<@URQ797WRW> do you mean setting `sonar.jacoco.reportPaths`?

Maybe set a breakpoint in the configuration code and look at the stack trace?

You are probably doing invalid things within `android { ... }` in `/home/ambition/Project/SuperCryptoKart/android/build.gradle`. Unfortunately the error message is not too helpful and you need to comment out all content and comment in line by line to find where the error is or similar tactics.
One of the reasons I exclusively use Kotlin DSL and not Groovy DSL, you instantly get type-safe build scripts, compile-time type checking, better error messages, and much better IDE support.

Check if your ide inserted autoimports at the top. If it did -- remove them and switch off autoimport.

Please don't split one topic across three threads. This makes it very hard to follow in the Threads view as the context of the other messages is missing. If you have additional information, either edit the original message or post to its thread please.

<https://youtrack.jetbrains.com/issue/KT-42944|Related>

apparently `-Xmx2g` works but the module kotlin compilations does fail for insufficient heap size, so it's not working as supposed to do

apparently2 `org.gradle.jvmargs=-Xmx2g` in `gradle.properties` fixes it

Don't write the same message in more than one channel

i'm sorry for that! It's my firt time here. But please help me! I'm trying to learn it to got a job, please answer me about my problem

But why are you asking in the Gradle community slack? I don't see any Gradle problem. Something is wrong with your Android values file. Maybe better ask in some Android community.

I'm sorry, but how can u see in the print, the error shows me the link to get help here.
 I just excluded the program and started it again.

Yes, but the link is wrong.
I never liked this non-sense advise.
It is always shown if a build fails, no matter for what reason.
It only makes sense if you actually need help with something Gradle related.
But your problem is not Gradle related, other than that you run the build using Gradle.

```configurations {
    configureEach {
        resolutionStrategy {
            eachDependency {
                // Let's never leak test frameworks on our runtimeClasspath again.
                if (requested.name == "groovy-all") {
                    throw RuntimeException("Don't ever use `groovy-all`. Use `groovy` directly and declare extra modules as needed.")
                }
            }
        }
    }
}```
We do this for `groovy-all`, I believe you can do the same for a group with `requested.group`

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

Thanks!

How does one determine whether there’s a BOM available for a given set of modules? It looks like <https://github.com/graphql-java/graphql-java/blob/master/build.gradle|graphql-java is published with Gradle>, but I don’t see a bom <https://mvnrepository.com/artifact/com.graphql-java|when I search on mvnrepository>.

<https://github.com/graphql-java/graphql-java/blob/master/build.gradle#L304> :cry:

BOM and Gradle Module Metadata are two different things that can both be useful, but this project publishes neither

so if you want to align versions, you'll have to do so yourself, which the document I linked earlier also describes how to do

So we’d have to use the “Align versions of modules without a published platform” instructions? Perhaps something like this?

```abstract class GraphQLJavaAlignmentRule implements ComponentMetadataRule {
    void execute(ComponentMetadataContext ctx) {
        def group = "com.graphql-java"
        ctx.details.with {
            if (id.group.startsWith(group)) {
                // declare that group's modules all belong to
                // the same virtual platform
                belongsTo("$group:virtual-platform:${id.version}")
            }
        }
    }
}

dependencies {
    components.all(GraphQLJavaAlignmentRule)
}```

One more question… is there a way to dynamically create an alignment rule, so I could have some sort of “alignGroup” function that I’d use like this:
```dependencies {
    components.all(alignGroup("com.graphql-java"))
    components.all(alignGroup("com.example.foo"))
    components.all(alignGroup("org.example.bar"))
}```
?

you could make your rule work on multiple groups

We have several projects where I could imagine wanting to align different sets of groups. We have a plugin we share across projects, so I’d like to be able to define `alignGroup` in the plugin, and then have each project just have a one-liner for each group it wants to align. I’m not sure how to do that given that `components.all()` apparently takes a class rather than an instance or closure, though.

```class AlignGroupRule implements Action&lt;ComponentMetadataRule&gt; {
    String group
    @Override
    void execute(ComponentMetadataContext ctx) { ... }
}
dependencies {
    components.all(new AlignGroupRule(group: "com.graphql-java"))```

but is there really a case where you recognize that a group _could_ be aligned, but you don't want to?

Good point.

Each of our projects, including the shared plugin, has its own git repo. The issue is if I’m working on project X, which depends on modules in “com.example.foo”, I don’t think I’d want to have to modify our shared plugin to align that group, and then let our CI publish it, and then switch each project to the updated plugin. At the same time, I’d rather not have the ~10 lines of boilerplate for the alignment rule in every project’s build file. That’s why I’m thinking it’d be nice to have the boilerplate in the plugin, and then each project can set up the alignment rules it needs based on its own dependencies.

Thanks for all of your help, <@U019L3NM4PK>

Unfortunately, some of my assumptions about graphql-java were incorrect. It looks like they don’t publish all of their modules in lockstep. Apparently they only publish graphql-java-extended-scalars on major versions. For example, for `com.graphql-java:graphql-java:17.2` one needs to use `com.graphql-java:graphql-java-extended-scalars:17.0` (the latter has no 17.2 version).

So it looks like I’d need to somehow tell Gradle to *round down* the version of graphql-java that’s being pulled in transitively to determine which version of graphql-java-extended-scalars we want. I don’t know how to express that as an alignment rule, or if it’s even possible.

I don't think there's a good solution to this unless upstream publishes a proper platform (BOM or otherwise). you could maintain your own with <https://docs.gradle.org/current/userguide/java_platform_plugin.html> but it would not be automatic

Yeah, I suspected that the right answer was “upstream should publish a platform”.

Thanks again!

the only clue i have found so far with --info is:

```Downloading <https://location/vvv/xxx-vvv.pom> to /tmp/gradle_download511304371605310413bin
Resource missing. [HTTP HEAD: <https://location/vvv/xxx-vvv.jar>]```

which seems wrong b/c the plugin pom points to a different location for the jar