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

Gradle Community

Dependencies that are marked as "optional" in a pom are only informational. They are completely ignore by Maven and Gradle. Not even their versions influence resolution.

The lib is <https://github.com/hantsy/togglz/blob/master/core/pom.xml#L33>  when includes the togglz into our project, build the project, it will includes the these two graalvm related jars.

Can you show an <https://stackoverflow.com/help/mcve|MCVE> that reprocudes the behavior?
The release of togglz-core does not even have the optional graalvm dependency declared.

Why don't you just publish both?
Usually if you split code to separate projects, I recommend to also publish them separately.

My goal is to have full control over a toolchain (this includes usage of a custom resolver) used in all published projects. And I found no way how to apply the toolchain with the resolver to the project with the resolver itself. So this is the only reason why I do it the way I described. 

Release one version without that control, then apply the last released version in the build?

Much like the Java compiler being written in Java. Initial version had to be in since other language.

I would lie if I said that I didn't think about that solution. In our company I have to make every single Gargle/build related stuff with "for dummies" phrase in my mind.
Even if your solution sounds right, it involves additional steps to be executed every time the implementation changes. My experience tells me, that this is no-go for this very situation. 

Even though I wouldn't do it, you can use a dynamic version, so that always the latest version is used. But you have to be very careful with backwards compatibility then.

Did you try running `flutter doctor --android-licenses` or whatever the linked page says you should be doing?

And besides that, your question has nothing to do with Gradle, so is not really appropriate for the Gradle Community Slack. :wink:

<@URQ797WRW> the error literally said "... Execution failed for task ':app:compileDebugKotlin'.
&gt; A failure occurred while executing org.jetbrains.kotlin.compilerRunner.GradleCompilerRunnerWithWorkers$GradleKotlinCompilerWorkAction
   &gt; Compilation error. See log for more details

* Try:
&gt; Run with --stacktrace option to get the stack trace.
&gt; Run with --info or --debug option to get more log output.
&gt; Run with --scan to get full insights.

* Get more help at <https://help.gradle.org> .."

Unfortunately, every failed Gradle build tells to get help here. But that is actually non-sense. This is for help with Gradle problems. You don't have a Gradle problem. Your code does not compile, probably because you made some syntax error or similar.

The error message from your last screenshot says that you want to use something that is compile for Java 11 or newer while using Java 8.

You cannot apply a plugin that is built by one project of a build to another project in the same build. Put the plugin in its own build and then build a composite build with it, then you can apply it.

<@URQ797WRW> thank you! That was the term I needed, the composite builds doc page has exactly this scenario too <https://docs.gradle.org/current/userguide/composite_builds.html#included_plugin_builds|https://docs.gradle.org/current/userguide/composite_builds.html#included_plugin_builds> . You saved me a headache...hope you have a good weekend

yep, same here, thanks for confirming :+1:

Please follow the last line of that message.

cc <@UAB9WQKJ4>

Probably the (or related to the) incident shown at <https://status.gradle.com/>

I think the constraint is in the right place (it shows in the scan - 3 times actually...).
But in order to downgrade, you need to make it strict:

```classpath("org.yaml:snakeyaml:1.33!!")

// or (long notation)

classpath("org.yaml:snakeyaml") {
  version { strictly("1.33") }
}```

thanks jendrik. It would be great to declare that somehow on the outgoing project wouldn't it?

Yes. I missed that in the scan. You can declare the strict constraint in ':build-tools-internal' and that should also work.
```dependency.constraints {
  implementation("org.yaml:snakeyaml:1.33!!")
}```

If the constraint is further up anywhere the tree, it wins.

Hi there. Building projects with Java 8 is still supported by the latest Gradle versions. Can you share more detail about your upgrade challenges?

Also check out these docs: <https://docs.gradle.org/current/userguide/upgrading_version_5.html>

Also this is good:

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

Kyle thanks for response. We had tried once and many failures though `./gradlew help --scan` does not list any deprecation.
We can give it another try but are we sure if we upgrade to 6, it would solve the incremental compilation issues as mentioned above?

The incremental compilation with changes to primitive constants has been fixed in 7.1. So you would need to upgrade to 7.x if you want that feature.

You can also consider using JVM toolchains to decouple the version used to run Gradle from the version used to build your code: <https://docs.gradle.org/current/userguide/toolchains.html>

<https://docs.gradle.org/current/userguide/declaring_repositories.html?&amp;_ga=2.157258680.203680463.1679890574-414046609.1679583910#sec:supported_metadata_sources|https://docs.gradle.org/current/userguide/declaring_repositories.html?&amp;_ga=2.157258680.203680463.1679890574-414046609.1679583910#sec:supp[…]_sources>
please ignore the above.

Btw I tried investigating where the dependency got transitively leaked from, but the output of `dependencyInsight` was hard to understand, I couldn't get any actionable insights from it

Did you define a range for that dependency, or a fixed version?
What did the `dependencyInsight` output, or are you maybe able to share a build scan?

I did not define neither a range nor a fixed version for the dependency, it must have came transitively.

I just tried re-running `dependencyInsight` and am encountering a problem, I'll try to get it to work and then I'll share the output

```16:51:06: Executing ':common:dependencyInsight --dependency com.fasterxml.jackson.core:jackson-core --configuration default -q'...

com.fasterxml.jackson.core:jackson-core:2.15.0-rc1
   variant "runtimeElements" [
      org.gradle.category            = library (not requested)
      org.gradle.dependency.bundling = external (not requested)
      org.gradle.libraryelements     = jar (not requested)
      org.gradle.usage               = java-runtime (not requested)
      org.gradle.status              = release (not requested)
   ]
   Selection reasons:
      - By constraint : dependency was locked to version '2.15.0-rc1'
      - By ancestor

com.fasterxml.jackson.core:jackson-core:{strictly 2.15.0-rc1} -&gt; 2.15.0-rc1
\--- default

com.fasterxml.jackson.core:jackson-core:2.15.0-rc1
+--- com.fasterxml.jackson:jackson-bom:2.15.0-rc1
|    +--- default (requested com.fasterxml.jackson:jackson-bom:{strictly 2.15.0-rc1})
|    +--- com.&lt;REDACTED&gt;.engprod:platform:4.1.33.0 (requested com.fasterxml.jackson:jackson-bom:+)
|    |    +--- default (requested com.&lt;REDACTED&gt;.engprod:platform:+)
|    |    \--- com.&lt;REDACTED&gt;.engprod:engprod-commons:2.3.91.0 (requested com.&lt;REDACTED&gt;.engprod:platform:2.3.91.0)
|    |         \--- default (requested com.&lt;REDACTED&gt;.engprod:engprod-commons:2.+)
|    +--- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.15.0-rc1
|    |    +--- default (requested com.fasterxml.jackson.datatype:jackson-datatype-jsr310:{strictly 2.15.0-rc1})
|    |    +--- com.&lt;REDACTED&gt;.engprod:engprod-commons:2.3.91.0 (requested com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.14.0) (*)
|    |    \--- com.fasterxml.jackson:jackson-bom:2.15.0-rc1 (*)
|    +--- com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.15.0-rc1
|    |    +--- default (requested com.fasterxml.jackson.dataformat:jackson-dataformat-xml:{strictly 2.15.0-rc1})
|    |    +--- com.&lt;REDACTED&gt;.engprod:engprod-commons:2.3.91.0 (requested com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.14.0) (*)
|    |    \--- com.fasterxml.jackson:jackson-bom:2.15.0-rc1 (*)
|    +--- com.fasterxml.jackson.core:jackson-databind:2.15.0-rc1
|    |    +--- default (requested com.fasterxml.jackson.core:jackson-databind:{strictly 2.15.0-rc1})
|    |    +--- com.&lt;REDACTED&gt;.engprod:engprod-commons:2.3.91.0 (requested com.fasterxml.jackson.core:jackson-databind:2.14.0) (*)
|    |    +--- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.15.0-rc1 (*)
|    |    +--- com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.15.0-rc1 (*)
|    |    +--- com.fasterxml.jackson:jackson-bom:2.15.0-rc1 (*)
|    |    \--- com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.15.0-rc1
|    |         +--- default (requested com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:{strictly 2.15.0-rc1})
|    |         +--- com.&lt;REDACTED&gt;.engprod:engprod-commons:2.3.91.0 (requested com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.14.0) (*)
|    |         \--- com.fasterxml.jackson:jackson-bom:2.15.0-rc1 (*)
|    +--- com.fasterxml.jackson.core:jackson-core:2.15.0-rc1 (*)
|    +--- com.fasterxml.jackson.core:jackson-annotations:2.15.0-rc1
|    |    +--- default (requested com.fasterxml.jackson.core:jackson-annotations:{strictly 2.15.0-rc1})
|    |    +--- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.15.0-rc1 (*)
|    |    +--- com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.15.0-rc1 (*)
|    |    +--- com.fasterxml.jackson.core:jackson-databind:2.15.0-rc1 (*)
|    |    \--- com.fasterxml.jackson:jackson-bom:2.15.0-rc1 (*)
|    \--- com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.15.0-rc1 (*)
+--- com.fasterxml.jackson.core:jackson-databind:2.15.0-rc1 (*)
+--- com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.15.0-rc1 (*)
+--- com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.15.0-rc1 (*)
\--- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:2.15.0-rc1 (*)

com.fasterxml.jackson.core:jackson-core:2.12.1 -&gt; 2.15.0-rc1
+--- com.google.cloud:google-cloud-firestore:2.2.4
|    +--- default (requested com.google.cloud:google-cloud-firestore:{strictly 2.2.4})
|    +--- com.&lt;REDACTED&gt;.engprod:engprod-commons:2.3.91.0
|    |    \--- default (requested com.&lt;REDACTED&gt;.engprod:engprod-commons:2.+)
|    \--- com.google.cloud:libraries-bom:19.0.0
|         +--- default (requested com.google.cloud:libraries-bom:{strictly 19.0.0})
|         \--- com.&lt;REDACTED&gt;.engprod:platform:4.1.33.0
|              +--- default (requested com.&lt;REDACTED&gt;.engprod:platform:+)
|              \--- com.&lt;REDACTED&gt;.engprod:engprod-commons:2.3.91.0 (requested com.&lt;REDACTED&gt;.engprod:platform:2.3.91.0) (*)
\--- com.google.cloud:google-cloud-storage:1.113.12
     +--- default (requested com.google.cloud:google-cloud-storage:{strictly 1.113.12})
     +--- com.&lt;REDACTED&gt;.engprod:engprod-commons:2.3.91.0 (*)
     \--- com.google.cloud:libraries-bom:19.0.0 (*)

(*) - dependencies omitted (listed previously)

A web-based, searchable dependency report is available by adding the --scan option.
16:51:07: Execution finished ':common:dependencyInsight --dependency com.fasterxml.jackson.core:jackson-core --configuration default -q'.```

trying to figure out where this coming from by looking at the `engprod-commons`  project now..

Personally, I find Build Scans™ much easier to read than `dependencyInsight`. Have you tried running your build with the `--scan` option? The searchable nature of the dependency tree is really nice in the UI.

`com.&lt;REDACTED&gt;.engprod:platform:4.1.33.0` has `com.fasterxml.jackson:jackson-bom:+` which means latest version available

I wish I could <@U02DGQN2WL9> but my company's policy prohibits using `--scan` because it sends sensitive build info to Gradle's Server which is against our security policy

<@URQ797WRW> is there a way to specify a dynamic dependency (e.g. `2.+` while also preventing unstable versions?

Björn is right - you never, ever want to publish a library that exposes a dynamic dependency like `com.fasterxml.jackson:jackson-bom:+`

Yes Gradle has an API to publish the _resolved_ version of the dependency in the metadata.

See Example 4 here: <https://docs.gradle.org/current/userguide/publishing_maven.html#publishing_maven:resolved_dependencies>

Oh, I didn't even realize the default behavior was to use dynamic dependencies in the published artifact! That seems like odd behavior, I would have expected that resolved dependencies would be the default behavior

If I understand correctly, this means that if I publish my Gradle plugin `foo`  version `1.0` that has a dynamic dependency `bar:+` , and at the time of publishing, the latest version of `bar` was `1.0` , but a month later `bar` releases version `2.0`, then someone using `foo:1.0` will transitively get the dependency `bar:2.0`  instead of `bar:1.0`?

It’s basically building a time-bomb into your library. As the docs state, this is exactly your use-case:

&gt; Example use cases for resolved versions:
&gt; • A project uses dynamic versions for dependencies but prefers exposing the resolved version for a given release to its consumers.


I’m sure the feature has good intentions; for example it’s not unreasonable to use a dynamic dependency like `foo:1.0.+` … this ensures that the latest patch release is always consumed. But you also take a risk that the owner of `foo` understands semver and never makes any breaking changes in a patch release.

I notice now that our plugin actually already uses `fromResolutionResult`

That’s good - then maybe you want to scope `bar:+` to a major version, like `bar:2.+` . This might help.

Maybe the plugin does, but `com.&lt;REDACTED&gt;.engprod:platform` does not?
Because that is the one with the dynamic version dependency.

And even worse it probably uses `enforcedPlatform`, as the constraint comes out with strict versions.
`enforcedPlatform` should almost never be used in an end-product except in rare edge cases, and practically never in a library project.
Gradle should even prominently warn you if you publish something with an enforced platform.

<@URQ797WRW> is there an article/blog post or something that explains why `enforcedPlatform` should not be used?

I learned it from <@UAFGSU86M>, not sure whether he blogged about it

All the docs say is
&gt; Using `enforcedPlatform` needs to be considered with care if your software component can be consumed by others. This declaration is effectively transitive and so will apply to the dependency graph of your consumers. Unfortunately they will have to use `exclude` if they happen to disagree with one of the forced versions.
&gt; 
&gt; Instead, if your reusable software component has a strong opinion on some third party dependency versions, consider using a <https://docs.gradle.org/current/userguide/rich_versions.html#sec:strict-version|rich version declaration> with a `strictly`.

Found it 7.4. but still something annoying.

a little bit of Google-fu can help

`"version catalog" site:<https://docs.gradle.org/> inurl:release-notes -inurl:milestone -inurl:rc`

<https://www.google.com/search?q=%22version+catalog%22+site%3Ahttps%3A%2F%2Fdocs.gradle.org%2F+inurl%3Arelease-notes+-inurl%3Amilestone+-inurl%3ARC>

try using testApi instead of testImplementation to add a dependency on the library - then it should be visible to the consuming project

``` Could not find method testApi() for arguments```
have "id java-library" in that build.gradle also.  Is testApi from a version later than 6.0.1?

ah, does the plugin apply the ‘plain’ Java plugin? Try using the <https://docs.gradle.org/current/userguide/java_library_plugin.html|Java Library> plugin instead

Thank you for responding, but still no joy:
```plugins {
        id 'java-library'
}
apply plugin: 'java-library'```
The above is from the file with testApi failure.

hmm, I’m misremembering something then. I just tried it locally and yes, testApi is not available with Java Library.

I have attempted api, implementation, testImplementation and testRuntimeOnly against that library.  Only testCompile works.  Something must be different in how various classpaths are populated and/or shared.

<https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_recognizing_dependencies|the docs> go into more detail about ‘implementation’ vs ‘api’ , and why they replace ‘compile’, but the short answer is that ‘compile’ is too leaky and overshares dependencies, even when they’re best not shared.

‘implementation’ is generally better because it’s more defensive, but sharing dependencies by defining them as ‘api’ can be useful sometimes (as you’re finding out!)

regular api vs implementation differences I understand.  Its this corner case with a static initializer / test library that is giving me grief.

Looking for a way to "leak" what ever testCompileOnly used to leak.

it is possible because I have testApi in some projects, I’m just trying to figure out what plugin is defining it…

I think it’s coming from the Kotlin JVM plugin, which you probably don’t want to add just to get testApi

instead it looks like the alternative is to use the test-fixtures plugin

<https://github.com/gradle/gradle/issues/8585#issuecomment-517152546>

docs about the plugin are here: <https://docs.gradle.org/current/userguide/java_testing.html#sec:java_test_fixtures>

I was avoiding java-test-fixtures.  Will try now.

I really recommend test fixtures, they’re a really neat way to share test utilities and keep the test sources clean. But in this case, you don’t need to dig into all of that. The plugin can be used just to provide the necessary Gradle config

This is a really old project.  But times require we upgrade / update.

1. apply `java-test-fixtures` in the providing subproject
2. expose the library using `testFixturesApi(...)`
3. in the consuming subproject, add a dependency using `testImplementation(testFixtures(project(":my-library")))` 

there’s no need to apply java-test-fixtures in the consuming subproject

did not work.  but that might just be me needing to play a bit.  syntax was accepted.

possibly more dependencies need to be exposed

--info suggests still same problem.  Not saying that means you are wrong.  Just my source of clues.

again, this is not new code.  worked before syntax changes for deprecation.

Gradle has a util for auto converting a Maven project to a Gradle project, and it will convert _all_ dependencies to be ‘api’ dependencies, because even if it’s not best practice it’s closer to how Maven dependencies work, so it will at least convert the Maven config to a Gradle project that works.

I mention this because it’s similar to migrating from ‘compile’ to ‘api’/‘implementation’

Adam.  Thank you again.  I have  to step away for a little bit while there is still light outside.  Will keep experimenting.

Actually, you can find `testApi` in the Gradle userguide (while it indeed does not exist :smile:)

Test source sets are not meant to be depended upon cross-project, so there usually is no `testApi` and also a reason why the `test-fixtures` were added I guess.

Btw.
&gt; ```plugins {
&gt;         id 'java-library'
&gt; }
&gt; apply plugin: 'java-library'```
is redundant.
You first apply the plugin properly the new way and then again the legacy way.
You should actually not have any `apply plugin:` anymore except for very special cases of plugins that break the `plugins { ... }` block when you are using Kotlin DSL.

@adam <@URQ797WRW> Follow up:  testFixtureApi did allow me to repair the dependency problem.  Still took an extra day to isolate the areas impacted.  Like I said, 156 subprojects.

Hey! This should help: <https://docs.gradle.org/current/userguide/jvm_test_suite_plugin.html#configure_the_test_task_for_a_test_suite>

Using that DSL you can configure the test task like normal.

This issue is not related to gradle? but maybe plugin what you're using to parse yaml file

<@U04R762LX7G>  it was not observed with 5.x and 6.x versions of gradle. 

Okey. That is integration issue between plugin and Gradle version. I'm sure that I had have to update different plugins because of new policy of Gradle 7. Can be that your plugin still use old methods to access files, this method is no more allowed in new Gradle. In conclusion: you have to upgrade your plugins too, or post in plugins repository to get some help 

This is resolved after modifying the path specified in $ref. I think the way the new plugin handles references from external files has changed.
<https://davidgarcia.dev/posts/how-to-split-open-api-spec-into-multiple-files/>

I'm trying to upgrade gradle from 6.x to 7.x

<https://github.com/gradle/gradle/issues/12283#issuecomment-1439226142>

Wops, I am even following that issue for a long time and I totally forgot about it 

any reason to use gradle-local.propeties instead of local.properties?

I guess from this comment (the plugin)

<https://github.com/gradle/gradle/issues/12283#issuecomment-902958139|https://github.com/gradle/gradle/issues/12283#issuecomment-902958139>

• personal preference
• it is what the gradle-properties-plugin uses (don't use it, it currently totally destroys task configuration avoidance)
• they are still Gradle properties, just local to the work tree

problem is there are other tools like AGP which uses local.properties so maybe it is possible to get a “duplicated file”

That AGP uses `local.properties` is imho another reason to name it `gradle-local.properties`.
Besides that I guess they just introduced it due to the lack of official support for such a file and they can just use normal project properties if official support were present.

I think I would use this order:

• command line, as set using `-D`
• `gradle-local.properties` in the project’s directory, then its parent project’s directory up to the build’s root directory
• Environment variables &lt;---------
• `gradle.properties` in `GRADLE_USER_HOME` directory
• `gradle.properties` in the project’s directory, then its parent project’s directory up to the build’s root directory
• `gradle.properties` in Gradle installation directory


I think it has sense cli and local properties that can be codegenerated on CI are over Environment Variables. But I am not sure if they should go above home directory one, or after it

That shouldn't change from how it is already.
Currently you have

• command line (-D for Gradle properties, -P for project properties)
• environment variables and system properties (I'm not sure right now which has precedence)
• various gradle.propeties files
As you can specify environment variables and system properties also from the command line,
I think they should take precedence over `gradle-local.properties`, so your line 2 and 3 swapped

I don't think you can. But the opposite (`dependencies`) is available as `buildEnvironment` and it should usually not be *that* much in there as in normal dependencies, so is usually sufficient.

<@U03FBR224AE> if you want to only depend on lib A : 1.0.0 then you can declare that you strictly depend on version 1.0.0. For example: `implementation("libA:1.0.0!!")`
For more details: <https://docs.gradle.org/current/userguide/single_versions.html>

Thanks for that, yeah I can do that in this case, which would mean that if Lib B tries to resolve something which only exists in 1.1.0 then that library would get a runtime crash right? Since it wouldn’t exist as I am forcing 1.0.0.

Now I’m already fixing this by bumping everything to 1.1.0, and updating my call-sites too, but I have been trying to figure out how this has happened in the first place and what I can do to avoid getting this issue in the future too. It really feels like I should’ve been getting a compile-time error for this, but I did not. Already have a disussion with someone on the kotlin <https://slack-chats.kotlinlang.org/t/10123513/i-m-using-compose-bom-2023-01-00-which-brings-in-androidx-co#0faec9a0-09d0-4f2f-8502-7749e77a8709|slack channel>, but I don’t think I still understand what’s going on exactly.

As it is on an open source project, I'd recommend looking at / sharing a build `--scan`. Basically similar information as `dependencies` and `dependencyInsight` provide, but nicer displayed and searchable and with some additional information. In most cases it is easier to investigate in there.

<https://scans.gradle.com/s/mnnza7duzvtb2/dependencies?focusedDependencyView=dependencies_or_failure&amp;toggled=W1s1XSxbNSw0XSxbNSw0LFs0MzgxXV1d>
This is the first time I’ve done this, now trying to learn how to navigate myself through there :smile:
Looking at the `androidx.compose.material:material:1.4.0-alpha04` in particular. And how in my code I got 1.3.1 (through androidx.compose:compose-bom:2023.01.00), and therefore get no warning that some APIs from in there have changed, but at runtime it’s using 1.4.0-alpha04, and it crashes as one of the function signatures changed in a backwards incompatible way (it’s annotated as experimental so that’s why it was done this way).
Not gonna lie, a bit overwhelming to navigate in there for the first time, I wouldn’t say I understand everything that I would like to, but gonna try and spend some more time at it.

Yeah, can be a bit overwhelming at first indeed. :slightly_smiling_face:

In which of the projects is the class that compiled but should have failed?

The crash was here <https://github.com/HedvigInsurance/android/blob/c5c5041c5ce1f620edcca990968f6abc70891d72/feature-businessmodel/src/main/kotlin/com/hedvig/android/feature/businessmodel/ui/BusinessModelScreen.kt#L57-L60|https://github.com/HedvigInsurance/android/blob/c5c5041c5ce1f620edcca990968f6abc70891d72/feature-businessmodel/src/main/kotlin/com/hedvig/android/feature/businessmodel/ui/BusinessModelScreen.kt#L57-L60>
So it's inside the ":feature-businessmodel" module

As you can see at <https://scans.gradle.com/s/mnnza7duzvtb2/dependencies?configurationFilter=WyJkZWJ1Z0NvbXBpbGVDbGFzc3BhdGgiLCJrb3RsaW5Db21waWxlckNsYXNzcGF0aCIsImNvbXBpbGVDbGFzc3BhdGgiXQ&amp;dependencies=androidx.compose.material:material:&amp;expandAll&amp;focusedDependencyView=dependencies_or_failure|https://scans.gradle.com/s/mnnza7duzvtb2/dependencies?configurationFilter=WyJkZWJ1Z0N[…]ial:&amp;expandAll&amp;focusedDependencyView=dependencies_or_failure>, that module does not have 1.4.0-alpha in the transitive deps, to it compiles against 1.3.1.
But `app` has 1.4.0-alpha in the transitive deps, so that is what `app` when it assembles everything together ends up with in the runtime classpath.

To get 1.4.0-alpha everywhere (who in the world publishes a dependency on a an alpha version? o_O), you could for example introduce a platform where you define that constraint and then make all your subprojects use that platform, so that you have 1.4.0-alpha everwhere where it is present.

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

Wow, so that is what is happening, I had no idea before experiencing this actually. I always thought the dependency decisions are made on a global level, and then used by all modules. But it does make sense that this decision happens on a module level, so that's why on my own source code it looked fine, but not on runtime.
This is certainly new to me, but very important to understand!

I will give this a try by making use of this platform feature.
Btw from this build scan, can I see where this alpha transitive dependency comes from? I imagine it either comes from another alpha version we may be using, or a library we've made ourselves, which does have some alpha dependencies but we're gonna kill soon anyway, hence it being a bit unmaintained like that.

Thank you both for helping out, I appreciate it so much! And thanks for letting me know about this --scan feature, definitely something to try using again in the future :blush:

You are told about it with every failed build. :-D

Haha well, Gradle tells me a ton of things on every failed build. In fact, enough things that my eyes have become blind to things that I see every day and automatically filter out :sweat_smile:

And yes, you can see where it comes from. Click it hover it (don't remember, I'm on mobile) then there appears an icon on the right to display details

yes, it’s been having trouble for a few days

<https://gradle-community.slack.com/archives/CAHSN3LDN/p1679908883992049> (<https://www.linen.dev/s/gradle-community/t/10113184/https-plugins-gradle-org-seems-to-be-having-some-issues-or-i#f85ff3b6-64ae-42d9-aaab-bad3f3ea9394|archive link>)

<https://status.gradle.com/>

Oh sorry I didn't scroll up. I did not know Gradle had a status page, thanks for linking :slightly_smiling_face:

Maybe you could leverage <https://github.com/uklance/gradle-dependency-export/> to get the job done?

This seems a good starting point, thanks!

Other than that, you could also give <https://github.com/oss-review-toolkit/ort> I'm working on a try. It's meant to create SBOMs, but in fact what you want is somehting like an SOMB (that also contains the URLs to the dependencies and not just their coordinates).

I'm working on revamping the Gradle analysis in ORT as we speak.

hey cool project! But ORT it seems to be very powerful but also very complex: I was hoping for a lightweight gradle plugin that I can easily run like any gradle tasks. Dependencies on Docker are a little out of scope for now...

ORT does not require Docker for Gradle project analysis. That's only required for other package managers / when doing more than just analysis.

I see, so I could just use the Gradle analysis to generate the BOM? Do you have an example of how the BOM looks like?

Here's an example, with the line highlighted you're probably interested in: <https://github.com/oss-review-toolkit/ort/blob/68f4fa173a17666bb71dbc8dcbc320252e2a0547/plugins/package-managers/gradle/src/funTest/assets/projects/synthetic/gradle-library-expected-output-app.yml#L86|https://github.com/oss-review-toolkit/ort/blob/68f4fa173a17666bb71dbc8dcbc320252e2[…]ssets/projects/synthetic/gradle-library-expected-output-app.yml>. Note that this is ORT's internal "SBOM" format. If you want something common like SPDX or CycloneDX, you'd have to also use the reporter tool.

Yep, this output seems to contain the URLs I'm looking for. Does it have also the plugins from `gradlePluginPortal()` needed during the build, but not included in the artifacts?

No. That's indeed a problem regarding your use-case. We focus on runtime dependencies (sort of); Gradle plugins required during the build are out of scope for us.

mmm yeah, than I have to keep searching :disappointed:
what about `gradle-dependency-export`? does that take into account also the gradle plugins?

I don't know. I've never used it myself, only looked at its source code partly.

<@U01N075J77D> I'm trying to run the plugin but it complains about some Javadoc stuff, even if I set it to not exporting it, so I decide to get the code and try to see if I can get these dependencies but I'm stuck here:
```val componentIds = config.incoming.resolutionResult.allDependencies.map { it.selected.id }```
<https://github.com/uklance/gradle-dependency-export/blob/master/src/main/groovy/com/lazan/dependency/export/MavenDependencyExport.groovy#L110>
`selected` doesn't seem to be there anymore and I have no clue where to find it, the code is 4 years old so maybe this was moved in recent versions of Gradle. Do you know perhaps where I can find this `selected`?

You probably need to cast `it` to `ResolvedDependencyResult` beforehand.

hey sorry to bother again but I'm not really familiar with Gradle plugins and, since you are and already looked at this code...
Would you say that these 4 fields are all `@Input` or are the something else?
<https://github.com/uklance/gradle-dependency-export/blob/master/src/main/groovy/com/lazan/dependency/export/MavenDependencyExport.groovy#L24>
```class MavenDependencyExport extends DefaultTask {
	public Collection&lt;Configuration&gt; configurations = new LinkedHashSet&lt;&gt;()
	public Map&lt;String, Object&gt; systemProperties = System.getProperties()
	boolean exportSources
	boolean exportJavadoc```

Sorry, I'm not very familiar with Gradle plugin development per se.

no worries, thanks anyway :slightly_smiling_face:

`debugImplementation("com.example:library-debug:1.0.0")`

`releaseImplementation("com.example:library-release:1.0.0")`

should work

Right. That's what I have now. I would like to replace that with a dependencySubstitution

<https://github.com/gradlex-org/java-ecosystem-capabilities|https://github.com/gradlex-org/java-ecosystem-capabilities>

first use something like that to teach Gradle that `-debug` and `-release` can't be used at the same time

then if you create a project with debug and release variants, each depending on the correct library variant, you can use that as your dependency, and anything that goes wrong will be caught

<@U019L3NM4PK> do you mean similar to <@U0482QZF7C3>'s suggestion?

Found a solution for this:

```allprojects {
    configurations.all {
        resolutionStrategy.dependencySubstitution {
            val substitutions = this
            substitutions.all {
                val dependency = this
                (dependency.requested as? ModuleComponentSelector)?.let {
                    if (it.group == "com.example") {
                        val buildType = attributes.getAttribute(BuildTypeAttr.ATTRIBUTE).toString()
                        val newModule = "${it.module}-$buildType"
                        dependency.useTarget(module("${it.group}:$newModule:${it.version}"))
                    }
                }
            }
        }
    }
}```

*`--warning-mode=fail` or the respective Gradle property*

That of course is then for all deprecation warnings

yeah that’s the problem - I want to target just that check

Well, you could use a custom Gradle build :slightly_smiling_face:

Or if you can use build scans, you can look there

<https://ge.spockframework.org/s/mbpm7ue73zibo/deprecations?expanded=WyI0IiwiMTciXQ>

the idea is to make our codebase compatible with 8.x on this feature and keep it that way, _before_ migrating to 8.x

Yeah, well, not without a custom Gradle build.
Or you add to the Gradle wrapper script that it fails if the warning appears in the output

I filed this issue!

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

Looks like it works but some tasks from `some-module` are being executed and they shouldn't

```:kotlin-test-testng:jsIrPackageJson SKIPPED
:kotlin-test-testng:jsIrTestPackageJson SKIPPED
:kotlin-test-testng:jsLegacyPackageJson SKIPPED
:kotlin-test-testng:jsLegacyTestPackageJson SKIPPED```

`-x ...` removes the task and also its dependencies that are not otherwise added from the task graph, so I would guess something else is depending on those tasks?

Yeah it is weird, I will check with other task if they are still there, maybe kgp executes them always 

you can easily check the successors of said tasks in the Gradle Enterprise timeline view of a Build Scan

Can you see the actual dependency there, or just the temporal ordering?

If I do `./gradlew publishToMavenLocal -x some-module:publish`, as `publish`  would run `publishToMavenLocal`, it is not executed on `some-module` , right?

You exclude `publish`, not `publishToMavenLocal`

if `publish` would be the only task that brings `publishToMavenLocal`, then excluding `publish` would make it not bring `publishToMavenLocal`.
But if anything else brings it to the task graph, like your explicit request to execute it or another task dependency, then it is still there.

Or you set the property you mentioned in `&lt;GRADLE_USER_HOME&gt;/gradle.properties`

``` GRADLE_OPTS="-Dorg.gradle.daemon=false --info"
➜  android-vente-privee git:(develop) ✗ export GRADLE_OPTS                            
➜  android-vente-privee git:(develop) ✗ ./gradlew build
Unrecognized option: --info
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.```

Ah, stupid me, `GRADLE_OPTS` of course are the JVM options, not the Gradle options

But well, you already mentioned yourself how to do it :slightly_smiling_face:

`GRADLE_OPTS="-Dorg.gradle.daemon=false -Dorg.gradle.logging.level=info"`

I found it after some testing and googling but I didn't know if --info and that flag would have the same effect

It does as documented at <https://docs.gradle.org/current/userguide/logging.html#sec:choosing_a_log_level>

Btw. why should you ever want to generally "disable" the Gradle daemon?

because my CI builds are failing with gradle killing the daemon... so I would like to try disabling it... log


```---- End of the daemon log -----
JVM crash log found: file:///PATH_TO_PROJECT/hs_err_pid53.log
FAILURE: Build failed with an exception.
* What went wrong:
Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)```

That will most likely not change anything.
Disalbing the daemon does not disable the daemon. :smile:

It just disables reuse of the daemon.
So your build always runs in a daemon, but that setting controls whether it keeps running after the build finished to run other builds, or whether it is shut down at the end of the build.

Investigate further why the builds are failing at random ?

You can try to disable the daemon, I just don't think it will change much.
You probably will still have those randomly failing builds and will need to investigate why.

Maybe you indeed need too much RAM, system is out of RAM and the OOM killer kills the daemon.
That's almost always the situation when I have seen such behavior with builds running on Linux.

it would be great if gradle could just tell me "hey I am getting OOM, give me more RAM" :stuck_out_tongue:

I will see what I can do. Thanks for the tips

That is like saying "It would be great if the victim could have told 'hey, I am getting shot from behind'". :smile:

Gradle cannot know when the OOM killer decides to kill it

Maybe you configure the JVM memory to be 6 GiB max while the system only has 4 GiB or similar things.

Or in older Docker versions Java was only able to see the RAM available in the host machine, not to the actual Docker instance

I don't think this is the case... the infra in the company is always updated... and I am using the latest <https://github.com/alvr/alpine-android/> image

I will try to update to JDK 17, maybe I can get more info with that

Or maybe it was with old Java, I don't remember exactly, just that there was an issue. And as it was quite some time ago, I didn't imply that this might be your issue, but that there can easily be issues that would make it impossible to even see that something is going havoc.

IIRC you need some relatively recent Java like 17 for cgroups v2 awareness, but v1 awareness was backported to later releases of 8 and 11, or something like that…

but I'm not sure how much that matters, I thought Gradle defaulted to setting `-Xmx512m -XX:MaxMetaspaceSize=256m` or something along those lines

Container support in on by default since jdk10 and 8u191

Better to always expose var to pass generic options and set xms/xmx/metaspace though

daemon isn't the only thing using memory though, there's tasks and workers that fork (and the kotlin compiler daemon, if you're using kotlin)

<https://docs.gradle.org/8.1-rc-1/release-notes.html#better-memory-management> should make some of those fit into available memory more reliably

Kotlin 1.8.20 is not officially released yet. JetBrains will announce when everything is synced to everywhere, as they always do.

<https://slack-chats.kotlinlang.org/t/542216/hi-something-strange-happening-to-my-gradle-groovy-project-w#dfa90cf4-57cf-49cd-9d87-6109291ec463>, <https://slack-chats.kotlinlang.org/t/474300/hey-i-know-kotlin-1-6-20-is-not-officially-released-but-it-i#57faf78d-e49b-40d1-a142-a0519d879b17>, etc.
&gt; release also includes all final checks, builds of libraries and ide plugins and publication into several different repositories, which can take 1-3 working days (usually 1-2)

Besides that, you define `mavenCentral()` as project repository.
But what you need is it as plugin respository in your settings script.
The default `gradlePluginPortal()` redirects to JCenter for missing libs which forwards to MavenCentral for missing libs.
But as MavenCentral has it, but JCenter returns 404, JCenter probably has some cache that remembered it didn't see the file.
So either declare MC as additional plugin repository before GPP, or just wait until the cache refreshes.

Especially as you should wait anyway until the release process finished as <@U019L3NM4PK> said. :slightly_smiling_face:

About 5 hours ago, Dependabot updated Kotlin from 1.8.10 to 1.8.20 in one of my repos but the branch build failed for the same reason.

Yeah, because it is not intelligent. It does not understand that until the blog post is out the release is not finished. It just sees the new version at MavenCentral and creates the PR. It does not even consider from which repository the dependency is pulled obviously.

Thx for clarification.
Adding mavenCentral  to `setting.gradle.kts` did the trick (at this mid release time).

```pluginManagement {
    repositories {
        gradlePluginPortal()
        mavenCentral()
    }
}```
I will see how this will play out with the next Kotlin update. If if will be picked to quickly again I will consider setting Renovate <https://docs.renovatebot.com/configuration-options/#stabilitydays|stabilitydays> option to delay this update.

It is every release that it gets picked up too early and multiple people here or in Kotlin slack complain that it does not properly work.

And I would put MC first.
Saves the detour through JCenter for all things directly available on MC and also compensates some of the regular JC outages.

Renovate fails all my builds as well, but the weird thing is that it's only JCenter that doesn't have this...
<https://plugins.gradle.org/m2/org/jetbrains/kotlin/kotlin-scripting-jvm/1.8.20/kotlin-scripting-jvm-1.8.20.pom> -&gt; 404
<https://repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-scripting-jvm/1.8.20/kotlin-scripting-jvm-1.8.20.pom> -&gt; OK

I though we established that GPP redirects to JC which pulls from MC.

Yes, but JCenter gives the 404.
Again, it probably has some cache and still thinks it is absent as the cache period didn't expire yet.

Ah, of course, caches everywhere :slightly_smiling_face:

Woohoo, the caches expired! Let there be (successful) builds!

you can use `--refresh-versions` flag too

For me, it was on GitHub Actions CI, and I think in some of the projects I don't even have Gradle cache.