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

Gradle Community

Well, is the keystore file where the build expects it?

```Failed to construct transformer:  Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:133:10)
    at stableHash (/Users/standby/Desktop/MobApp/app/android/node_modules/metro-cache/src/stableHash.js:19:8)
    at Object.getCacheKey (/Users/standby/Desktop/MobApp/app/android/node_modules/metro-transform-worker/src/index.js:647:7)
    at getTransformCacheKey (/Users/standby/Desktop/MobApp/pickrr-app/android/node_modules/metro/src/DeltaBundler/getTransformCacheKey.js:32:19)
    at new Transformer (/Users/standby/Desktop/MobApp/pickrr-app/android/node_modules/metro/src/DeltaBundler/Transformer.js:180:28)
    at /Users/standby/Desktop/MobApp/app/android/node_modules/metro/src/Bundler.js:58:29
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}
error Cannot read properties of undefined (reading 'transformFile').
TypeError: Cannot read properties of undefined (reading 'transformFile')
    at /Users/standby/Desktop/MobApp/app/android/node_modules/metro/src/Bundler.js:95:34
    at Generator.next (&lt;anonymous&gt;)
    at asyncGeneratorStep (/Users/standby/Desktop/MobApp/pickrr-app/android/node_modules/metro/src/Bundler.js:14:24)
    at _next (/Users/standby/Desktop/MobApp/app/android/node_modules/metro/src/Bundler.js:36:9)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
info Run CLI with --verbose flag for more details.

&gt; Task :app:bundleReleaseJsAndAssets FAILED
Execution failed for task ':app:bundleReleaseJsAndAssets'.
&gt; Process 'command 'node'' finished with non-zero exit value 1```
this type of error is coming when i am tring to create a build using android studio.

Well, that has even less to do with Gradle.
That Gradle build is calling some Node.js process which is failing.

As I said in the other thread already. :slightly_smiling_face:

Yes, i have tried it by downgrading the node version but not worked.
if you have any suggestion then please provide.

<https://stackoverflow.com/questions/69665222/node-js-17-0-1-gatsby-error-digital-envelope-routinesunsupported-err-os>

You probably need to show what you tried, because it is pretty unclear. Especially what you mean with CLI vs. "part of build.gradle".
If you run a task from CLI it also just executes what you define accordingly in `build.gradle`.
And another thing that does not match is, that you speak of "calling a task in build.gradle", because you cannot call tasks. You define tasks and you define dependencies between tasks.
So it is most probably that you got some Gradle principle wrong.
Please show what you tried and what you do exactly where the behavior is not what you expect.

Sorry if my question was confusing. So right now, my build.gradle looks something like this
```buildscript {
…
}

intellij {

patchPluginXml {
  version.set("<http://xxx.xxx|xxx.xxx>")
}

runPluginVerifier {
	println("Inside runPluginVerifier")
	distributionFile.set(file("path"/to/plugin/artifact.zip))
}
}```
When I build the wrapper and my project, the build script is executed successfully with the println statement in the console. But it doesn’t generate any report folders.

But when I execute the command ./gradlew runPluginVerifier, it will run with the default options and generate the expected report folders.

Actually, configuring the tasks within the `intellij { ... }` block is little helpful.
It should be outside the block as there it belongs.
Having it inside is just doing nothing and just confusing readers.

Besides that, it is still unclear to me what you are doing where it does not behave as expected.
You say when you call the task, it is executed as expected but with default values, not with what you configured.
You say when you do &lt;what?&gt; you expect it to be executed, but it is not, but that the `println` is shown.

Actually, I would say, that the `println` is always shown as you work against task-configuration avoidance.
But that if the task is executed, it should use your configured values.
It is still unclear to me what you do when you expect the task to be run but it is not.
Also, you just set the `distributionFile` property of that task, you do not in any way change when or under which conditions it will be executed.

Iirc I usually configure it so that signing is required if it is a release verison but optional if it is a snapshot version.
That way snapshot version will still be signed if the signatory is configured, but just not be done if it is not configured and it is a snapshot version.

That's what I have too, along with `useGpgCmd()` to <https://docs.gradle.org/current/userguide/signing_plugin.html#sec:using_gpg_agent|use the GPG agent>, and that configures a signatory IIUC, so there'll always be a signatory and signing wil always be performed , irrespective of `required`.

Maybe only call that method if the necessary things for signing are present or something like that?
Alternatively, configure the GHA workflow to have the necessary signing configuration.

So, anyway, you'd lean towards conditional signature? Even though there's a difference in usage too? (publication was only used when… publishing –to an external repo–, and is now used for testing during the build; testing never needs signing)

What do you mean by "difference in usage"?

If you don't get the signatory not set when appropriate, you could maybe also disable the signing task when appropriate.

&gt; What do you mean by "difference in usage"?
Testing makes use of publishing but that's mainly an implementation detail to make the JARs accessible to the TestKit-driven builds, along with the dependency metadata. As long as I have a way to use the lib and processor libs in the test builds, I don't care whether that uses publishing or not (for this specific project, I could use an included build; because I don't have a test matrix with different Gradle versions; if that was the case, I couldn't do it as that would mean running the –included– build with various Gradle versions).
So if reusing the existing publishing configuration breaks the workflow (by requiring signing), then maybe it just shouldn't be reused, as the *goal* is not to reuse it: it's just tentatively reused because it's already there.

Well, yeah, I guess separate publication should be fine too.
Maybe even cleaner.
I didn't create such a build yet, so I do not have practical experience with it.

Fwiw, the only issue with multiple publications AFAICT is that you then need to disable publication/repository combinations to decide what you publish where: <https://docs.gradle.org/current/userguide/publishing_customization.html#sec:publishing_maven:conditional_publishing>

Fwiw, here it is:
<https://github.com/tbroyer/gradle-incap-helper/blob/4a412095eb1763dc20ff34ba9a4f28553878ef00/build-logic/src/main/kotlin/local/maven-publish.gradle.kts#L88-L128|https://github.com/tbroyer/gradle-incap-helper/blob/4a412095eb1763dc20ff34ba9a4f28[…]ef00/build-logic/src/main/kotlin/local/maven-publish.gradle.kts>
<https://github.com/tbroyer/gradle-incap-helper/blob/4a412095eb1763dc20ff34ba9a4f28553878ef00/integTest/build.gradle.kts>
<https://github.com/tbroyer/gradle-incap-helper/blob/4a412095eb1763dc20ff34ba9a4f28553878ef00/integTest/src/test/kotlin/net/ltgt/gradle/incap/integTest/IncrementalAnnotationProcessorProcessorIntegrationTest.kt#L33-L49|https://github.com/tbroyer/gradle-incap-helper/blob/4a412095eb1763dc20ff34ba9a4f28[…]gTest/IncrementalAnnotationProcessorProcessorIntegrationTest.kt>

it seems, privilage was set as `readonly`  under securityContext. Removed below from helm chart fixed the issue.
```securityContext:
  capabilities:
    drop:
      - ALL
    readOnlyRootFilesystem: true
    runAsNonRoot: true
    runAsUser: 1000```

Looks like a problem with Android Gradle plugin. I would try to update the version of AGP first.

ok it was reported yesterday and already closed:
<https://github.com/gradle/gradle/issues/23586>

Is related to AGP

Hello <@U04KPN0LW4W> welcome to this slack!
We recommend putting such a stack trace as a thread. here are some other recommendations <https://gradle-community.slack.com/archives/CA7UM03V3/p1671735195847199>

Which version of IDEA are you using? Do you have `jcenter()` in the build scripts?

Nah, those are the JCenter redirects from the plugin portal. But it works for me, at least now. I'd say, just try again. If it still does not work, I'd guess you have or needed some proxy or similar in your network?

I use IntelliJ version 2022.3.1; jcenter() does not exists in my project build.gradle or settings.gradle file. Only mavenCentral() there exists in build.gradle's repositories.

I don't know about M1 support, but you might want to have a look at <https://nokee.dev/|https://nokee.dev/>

I'm not aware it costs anything at all. As far as I know it is FOSS. What makes you think it costs?

do not want to commit time if this is going to be rejected by management due to cost.

<@UBTK9PLRM> Nokee is not commercial, is it?
Does it support M1 macs?

Basically, this commit gives gradle M1 support.  So my question is can this be done manually within a version 6.0.1 build.gradle file:

<https://github.com/gradle/gradle/commit/35455d90c9bb16390cf10fef81e4b9da9f658c15>

It's not possible to do without using a lot of internal API. Using internal API, there is almost always a way to hack something into Gradle. :) But it's quite complicated to wrap your head around it.

Nokee usually doesn't help in cases of unsupported architectures/tool chains, as it also builds on top of what Gradle core provides in this area.

I am in the process of creating a sample of how you can use the Tasks for native compilation without the whole toolchain setup around it. The goal is to use them for embedded development (cross-compile for other architectures). I don't know if it helps in your case, but maybe:

<https://github.com/jjohannes/plain-c>

I did this with latest 7.x but it should work with Gradle 6.x as there was basically no progress in that area since then I think.

There is a lot to unpack here and I can see some misinformation around native support in Gradle as well as over simplification. First off Nokee is free. It’s the continuation of the native support in Gradle. I’m pretty much the reason native support exists in Gradle in the first place and Nokee is a continuation of this work.

&gt; Nokee usually doesn’t help in cases of unsupported architectures/tool chains, as it also builds on top of what Gradle core provides in this area.
As far as this comment, it’s not true that Nokee doesn’t help for unsupported architectures/tool chains. It may be “more complicated” than what it should be, but it’s definitely possible to build for M1 using the latest snapshot. Nokee fixed several issues with the “newer” native support (aka `cpp-library`/`cpp-application`) around architecture supports.

&gt; I am in the process of creating a sample of how you can use the Tasks for native compilation without the whole toolchain setup around it. The goal is to use them for embedded development (cross-compile for other architectures).
It’s an interesting idea, and I would be curious how this actually work in real life project. I done about 4-5 different modelling for native as part of Nokee to explore and question the “older” and “newer” core native support and a simple “per-task” approach usually hits a wall pretty early. The current Nokee modelling focus on the middle model (variant management). Recently, we worked on composition which would be more of the higher level but it’s not the main focus at the moment. Task-level will be tackled as some point but I doubt it will ever bit the main focus because of all the other modelling that users needs in order to create a functional native build. In general, the task level is what Nokee calls the source sets which include source/headers management, incoming compile dependencies, toolchain management (local, remote), source/target compatibility, and compile task. As we can see compiling sources requires quite a bit of elements to work together. This is not to say that it cannot be approximated, but then you hit the chance of having weaker up-to-date checking or requiring to have intimate knowledge of the tool to use for building which defeats the core idea of native support in Gradle.

If you have an example of what you are doing (or trying to do) with Gradle core native support, I can guide you to an equivalent in Nokee.

I think it should be this one:
<https://docs.gradle.org/current/samples/sample_incubating_publishing_convention_plugins.html>

Could you maybe open an issue to <https://github.com/gradle/gradle|gradle/gradle>?

Oh, it should be this one, my bad: <https://docs.gradle.org/current/samples/sample_incubating_java_modules_multi_project_with_integration_tests.html>

Opened <https://github.com/gradle/gradle/issues/23614>

Are you sure that's a good idea?
NONE is really very rarely helpful.
May I ask why you think relative is still too strict?

Sure thing :slightly_smiling_face: The Plugin adds a Code Quality Check. And the tool it uses accepts a config xml file via command line arg. IMO, the result of the task is determined by the content of this config file and not its location.

Also, `PathSensitivity.NONE` really does not play well with `TextResource`

I guess you mean RELATIVE does not play well with text resources? :slightly_smiling_face:

Well, for the latter part you could have a task that copies the textresource to some location that always has the proper same relative path, like copying to `temporaryDir` of the task, or copying to `layout.buildDirectory`.

Changing those annotations of an existing task is not trivial afair.
I'm not 100% sure, you might try to subclass the task and override the property in question.
If that does not work, you might only have the choice to monkey-patch the task class by copying it to your `buildSrc` and fixing what you need to, adding some mechanism to make sure you remember to update that file when you change the plugin version.
`buildSrc` classes are in a class loader above the project classpath class loaders so classes in it will be preferredely used.

Alright :slightly_smiling_face: Thanks for the info :slightly_smiling_face: Guess I'll go with the first solution

not sure what you mean. `gradle.startParameter.isContinueOnFailure`?

 but this would be for all tasks running in that build right? I want to ignore only one of them 

well if you want a task to not fail, you could probably do something horrible like
```task.configure {
    val existingActions = actions
    val wrappedAction = Action&lt;Task&gt; {
        try {
            for (action in existingActions) action.execute(this)
        } catch (e: RuntimeException) {
            logger.error("Exception: ", e)
        }
    }
    actions = listOf(wrappedAction)
}```
but I don't think there's a way to simulate `--continue`'s behavior of "on failure, continue building other non-dependents, but don't build dependents and fail the build at the end" on just a single task

I was imagining that. The use case was avoiding crashing when creating two networks with the same name with a docker plugin. But I found it is exposing a docker client and I can check if the network exists on `onlyIf` which should be a better approach.

Thank you anyway :slightly_smiling_face:

Yes, using `onlyIf` seems better in that case.
But other than that, there are some tasks that explicitly support such a configuration like test tasks that have a property for not failing on failed tests.
But other than that, just what <@U019L3NM4PK> shows, wrapping the actions, catching exceptions.

docker usage seems like it would be better handled with a <https://docs.gradle.org/current/userguide/build_services.html|shared build service>. in your case, wouldn't there still be potential concurrency issues with `onlyIf`?

Not sure tbh as I am using a third party Gradle plugin. All I have tested is working currently, but maybe if two task run in parallel I can get a concurrency issue, currently I only have one

To take a look at what I'm working on:
<https://github.com/sbabcoc/Selenium-Foundation>

I've tried updating both `gradle.properties` and properties specified for the `clean`/`build`/`test` tasks, and I get the same bad behavior.

Never mind... too many settings. I discovered that I'd set an overriding program argument in the Gradle properties for my project.

For the `eclipse` plugin, this project-level setting or the same value in `gradle.properies` determine the content of the `.classpath` file it assembles.

For the Gradle tasks (e.g. - `test`), the properties need to be assigned in the task launch configuration.

I didn't fully get what you want, but to answer your initial question, no, that's a hen-and-egg problem. It is designed in a way so that a settings plugin can define a version catalog. But that means that the version catalog is not available before the settings are evaluated.

Basically I want to use the version catalog from platform 1, but I want to pull the version for platform 1's version catalog out of platform 2's version catalog.

I think you need to clarify if you are using maven or gradle. To add another project in gradle you can simply add it as an `include`  in your `settings.gradle`.

Since `settings.gradle` is scriptable it's just a simple if statement to exclude it based on that condition.

Of course as the question title, I am confused in a Gradle project.

Is there a simple guide for it? I am really a newbie of Gradle.

While it is most probably not a good idea, you can simply use an `if`, checking for a Gradle property. Both DSLs are Turing-complete languages.

what is the better solution, use a custom task for the specific requirement?

Hard to say generically, that heavily depends on the concrete situation.
Maybe a separate subproject could be appropriate.
Or maybe a feature variant.
Or really the `if`s.
Really hard to say.

I do this thru conditionally-included sub-configurations. I define a Gradle property and use this to decide which to `apply from`.
<https://github.com/sbabcoc/Selenium-Foundation/blob/master/build.gradle#L25>

This replicates Maven profiles pretty closely.

I think the most feasible path is via <https://youtrack.jetbrains.com/issue/KT-52748/Export-compiler-warnings-and-errors-into-file|https://youtrack.jetbrains.com/issue/KT-52748/Export-compiler-warnings-and-errors-into-file> but it'll require changes to the Kotlin Gradle Plugin

why would you add it conditionally? wouldn't it be easier to execute it conditionally instead?

This would be the workaround. But it would be cleaner not to create it at all (and it is less confusing in the task list in the ide)

How would the property be provided? Because you can simply read the property during the configuration phase and wrap the `tasks.register` call inside an if block:
```if (property) {
    tasks.register&lt;MyTask&gt;("myTask)
}```

Yeah, but this requires evaluating the Property by calling get(). The user should set a value of type Property and based on this value I will create the tasks.

in that case you'll require an `afterEvaluate` I think

I would advise against doing that though, it potentially messes with all sorts of optimisation strategies employed by gradle.

This is exactly I want to prevent :D In theory it should be possible by simple passing a transformer here: <https://github.com/gradle/gradle/blob/836be3907064dec84acf62815c120d950bca77fd/subprojects/core/src/main/java/org/gradle/api/internal/tasks/DefaultTaskContainer.java#L416>

<https://github.com/gradle/gradle/blob/836be3907064dec84acf62815c120d950bca77fd/subprojects/core/src/main/java/org/gradle/api/internal/tasks/DefaultTaskContainer.java#L740-L743|https://github.com/gradle/gradle/blob/836be3907064dec84acf62815c120d950bca77fd/sub[…]in/java/org/gradle/api/internal/tasks/DefaultTaskContainer.java>
I mean, clearly gradle doesn't want you to do that, so I'm sure they have a reason :shrug:

Gradle needs to build a task dependency tree (after configuration stage) before it even begins executing tasks.

How would a property, that you expect to be evaluated at execution time, influence the task tree which is built at configuration time? :thinking_face:

Properties (or Providers) are evaluated during configuration time, otherwise you can't configure your build. You can also use `addLater` for dependencies though.

Yes you can evaluate providers whenever. But I’m taking
&gt; Yeah, but this requires evaluating the Property by calling get().
to mean that you don’t want to evaluate it at configuration time?

Yes, I don't want to call get() explicitly by myself. Instead, you should use `set` and let Gradle handle calling `get` to lazy configure your build.

you can use rich versions, for example specifying `17.+` to get the latest v17 - but only within v17.

And without changing your build too much (no change to dependency declarations at least), Gradle has a dependency locking mechanism: <https://docs.gradle.org/current/userguide/dependency_locking.html>

And are you sure it is accessbile via HTTP, or do you only see it in the Artifactory UI?
Do you maybe need to use some proxy to access it?
Does maybe `--info` or `--debug` give more information?

I am seeing this issue <https://github.com/gradle/gradle/issues/22236> but I am using Gradle 7.6 and it was working before updating Kotlin.

Other tests that are failing are calling the task `:dependencies`

I've tried a bunch of things on the `implementation("...").attributesSchema { ... }` API but this API seems pretty obtuse for matching a specific value and nothing I throw at it seems to have any effect

I'm left with the ambiguity above and not sure how to get past it

I feel like I'm in the wrong API for specifying the consumer's intent

How would I say that I want `Attribute.of("net.devrieze.android", Boolean::class.javaObjectType)` to equal `false`?

`implementation("...").attributesSchema { ... }`?
It should be `dependencies.attributesSchema { ... ]` or probably `dependencies { attributesSchema { ... } }`.
You need to register a custom attribute in the attribute schema and then you have to request it, either by setting the attribute on the configuration that is going to be resolved, or on the dependency directly.

How does one do `setting the attribute on the ... dependency directly`?  That was what I was attempting to do with `implementation("...").attributesSchema { ... }`

actually, I short-handed that wrong.  More accurately, it was: `implementation("...") { attributesSchema { ... } }`

attributesSchema is not defined in that scope, so you call it on the outher scope where it belongs and where you need to add your custom attibute to the attribute schema

And I strongly advice to use Kotlin DSL.
You will get type-safe build scripts and amazingly better IDE support out-of-the-box. :slightly_smiling_face:

I also tried `dependencies.attributeSchema { ... }`  with the same result.  I abandoned kotlin-dsl because it make the gradle/project kotlin version coupling issue far worse than without it (but that's a separate issue)

&gt; because it make the gradle/project kotlin version coupling issue far worse
Not sure what you mean.
For build logic the Kotlin version is fixedly given by the Gradle version you use.
But in any way the project Kotlin version is completely independent of that.

Did you just do the `dependencies.attributeSchema` and ignored what I said multiple times already?

If yes, I'm not sure how much clearer I can say, that you need to add the custom attribute to the schema AND declare that you request it on the configuration or on the concrete dependency

Just adding the attribute to the schema is not enough, just requesting it is not enough, you have to do both

yeah, I can declare the attribute fine but I can't for the life of me figure out how to `declare that you request it on the configuration or on the concrete dependency`

It would maybe also help if you would provide an MCVE of what you tried, then it is clear what you did and what you did not :slightly_smiling_face:

I already told you, to subtract "schema", so for example `implementation("foo") { attributes { attribute(...) } }`, or similar on the configuration that is going to be resolved

hmm, that must be kotlin-dsl- provided.  I don't see `attributes` on `DependencyHandlerScope`.

I was hoping for someone to point at an existing repo with an example of how to do this but looks like I need to spin up the MCVE instead

Why would you expect `attributes` on `DependencyHandlerScope`?

because `implementation("foo") { this }` is a `DependencyHandlerScope` and you suggested to use `implementation("foo") { attributes { ... } }`

`ExternalModuleDependency`  to be precise

ah, I think the IDE is confused due to not being able to sync due to the root issue

Btw. did you actually have a look at the docs too?
They also have examples.
<https://docs.gradle.org/current/userguide/variant_attributes.html#sec:declaring_attributes>

yeah, nothing in the docs seemed to work.

Then I fear you really need to provide the MCVE.
I at least do not have a repo to share, sorry.

kk.  Based on what I'm seeing this might be a bug anyhow, at which point I'd need the MCVE regardless.  I'll start there.  Thanks for trying to get me through it though

FYI - turns out this was a bug relating to attribute specification in included builds: <https://github.com/gradle/gradle/issues/23668>

Maybe some other dependency depends on it?
You should be able to use the `dependencyInsight` task to find out why a specific library is contained in a specific configuration

Thanks, but I have checked this dependency is only once and only in compileOnly

Well, if I make a war project and add that compile-only dependency it does not land in the war.
I guess without an <https://stackoverflow.com/help/mcve|MCVE> it will be impossible to help.

Well, what should we say with that little information?
Do not call `afterEvaluate` after the project was already evaluated. :slightly_smiling_face:

Actually best is to never call `afterEvaluate` ever, in most cases it is just symptom treatment and not a proper solution.

Could well be that it even did not work with 6.5, but that some version between it and 7.4 added a check for such a useless call.

Full logs are
```Importing 3 trusted certificate(s)
Importing certificate gradle-certificate-001
Certificate was added to keystore
Importing certificate gradle-certificate-002
Certificate was added to keystore
Importing certificate gradle-certificate-003
Certificate was added to keystore
WARNING: Delegating to 'start' - this behaviour has been deprecated and will be removed in a future release. Please use the 'start' command directly.
Starting Gradle Enterprise build cache node (13.2) ...
ERROR: Unable to start SSL - failed to build SSL context.
The following exception trace may provide more information:
javax.net.ssl.SSLException: failed to set certificate and key
	at io.netty.handler.ssl.ReferenceCountedOpenSslServerContext.newSessionContext(ReferenceCountedOpenSslServerContext.java:138)
	at io.netty.handler.ssl.ReferenceCountedOpenSslServerContext.&lt;init&gt;(ReferenceCountedOpenSslServerContext.java:79)
	at io.netty.handler.ssl.ReferenceCountedOpenSslServerContext.&lt;init&gt;(ReferenceCountedOpenSslServerContext.java:62)
	at io.netty.handler.ssl.SslContext.newServerContextInternal(SslContext.java:480)
	at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:606)
	at com.gradle.ratpack.v.b.a(SourceFile:51)
	at com.gradle.buildcache.node.a.a$a.a(SourceFile:184)
	at com.gradle.ratpack.k.e.a(SourceFile:222)
	at com.gradle.ratpack.k.e.a(SourceFile:137)
	at ratpack.server.internal.RatpackServerDefinition.build(RatpackServerDefinition.java:43)
	at ratpack.server.internal.DefaultRatpackServer.lambda$buildUserDefinition$6(DefaultRatpackServer.java:269)
	at ratpack.impose.Impositions.impose(Impositions.java:117)
	at ratpack.server.internal.DefaultRatpackServer.buildUserDefinition(DefaultRatpackServer.java:267)
	at ratpack.server.internal.DefaultRatpackServer.start(DefaultRatpackServer.java:154)
	at com.gradle.buildcache.node.a.a.a(SourceFile:96)
	at com.gradle.buildcache.node.b.h.a(SourceFile:225)
	at com.gradle.enterprise.a.a.c(SourceFile:62)
	at com.gradle.enterprise.a.a.call(SourceFile:21)
	at picocli.CommandLine.executeUserObject(CommandLine.java:1953)
	at picocli.CommandLine.access$1300(CommandLine.java:145)
	at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2358)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2352)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2314)
	at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
	at picocli.CommandLine$RunLast.execute(CommandLine.java:2316)
	at picocli.CommandLine.execute(CommandLine.java:2078)
	at com.gradle.enterprise.a.a.a(SourceFile:84)
	at com.gradle.enterprise.a.a.b(SourceFile:89)
	at com.gradle.buildcache.node.b.g.a(SourceFile:45)
	at com.gradle.enterprise.a.a.c(SourceFile:62)
	at com.gradle.enterprise.a.a.call(SourceFile:21)
	at picocli.CommandLine.executeUserObject(CommandLine.java:1953)
	at picocli.CommandLine.access$1300(CommandLine.java:145)
	at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2358)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2352)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2314)
	at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
	at picocli.CommandLine$RunLast.execute(CommandLine.java:2316)
	at picocli.CommandLine.execute(CommandLine.java:2078)
	at com.gradle.enterprise.a.a.a(SourceFile:84)
	at com.gradle.enterprise.a.g.c(SourceFile:35)
	at com.gradle.buildcache.node.BuildCacheNodeMain.main(SourceFile:9)
Caused by: java.security.KeyStoreException: Key protection algorithm not found: java.security.KeyStoreException: Certificate chain is not valid
	at java.base/sun.security.pkcs12.PKCS12KeyStore.setKeyEntry(PKCS12KeyStore.java:688)
	at java.base/sun.security.pkcs12.PKCS12KeyStore.engineSetKeyEntry(PKCS12KeyStore.java:585)
	at java.base/sun.security.util.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDelegator.java:111)
	at java.base/java.security.KeyStore.setKeyEntry(KeyStore.java:1174)
	at io.netty.handler.ssl.SslContext.buildKeyStore(SslContext.java:1113)
	at io.netty.handler.ssl.ReferenceCountedOpenSslServerContext.newSessionContext(ReferenceCountedOpenSslServerContext.java:123)
	... 41 more
Caused by: java.security.KeyStoreException: Certificate chain is not valid
	at java.base/sun.security.pkcs12.PKCS12KeyStore.setKeyEntry(PKCS12KeyStore.java:635)
	... 46 more

Removing 3 existing trusted certificate(s)
Removing existing certificate gradle-certificate-001
Removing existing certificate gradle-certificate-002
Removing existing certificate gradle-certificate-003```

From the stacktrace I'd say your certificate chain is not ok.
The code that fails checks that issuerDN and subjectDN are the same for two adjacent certificates in the chain and that there are no loops in the chain.

Okay, thanks. I'll try to check it again.

<@URQ797WRW> thanks. you were right. it seems that certificates in the chain are not connected via issuerDN and subjectDN.
But still...
`openssl verify -CAfile trusted-ssl.crt -x509_strict ssl.crt`  return OK.

Where does this restriction with issuerDN and subjectDN came from? Sorry I'm not familiar with all these certificate things. I would appreciate any tips - then I would come to our network admins with some arguments to reissue the certificate chain.
Thanks again.

If the DNs do not match, there simply is no chain.
The subject DN is what identifies the ceritifacte.
So if certificate with subject DN `foo` issues certificate with subject DN `bar`, then it has to contain the issuer DN `foo` to build a chain, otherwise the certs are just two certs.
Maybe you just miss some intermediate certificate.

That is also nothing Gradle specific actually.
The error comes from classes in the JRE itself that verify the chain.

Maybe it was a temporary hickup, try again using `--refresh-dependencies`.

Thanks for getting back to me! I have tried that, but I'm getting the same result

Are you sure you do not have some firewall or need some proxy configuration?
I just tried and it works fine here with that plugin from plugin central.

Found the answer. Somehow my java symlink had been deleted.

Probably because some Java with broken certificates was uses that was not able to open the https connection properly I guess

Sounds right. The way I found the error was kind of odd. I copied the `gradle-enterprise-init.gradle.kts` file from the docs and made an `init.d` folder in my `.gradle` directory to hold it. Once i did that it gave me an error that it wasn't able to find the certificates file. That's what made me look and realize the symlink it was trying to follow was gone.
Once I restored the symlink I had to remove the `init.d` folder, since we aren't set up to use that. But after that it worked.

That plugin is the Android Gradle plugin and the task code is here: <https://android.googlesource.com/platform/tools/base/+/studio-master-dev/build-system/gradle-core/src/main/java/com/android/build/gradle/internal/tasks/DeviceProviderInstrumentTestTask.java#652|https://android.googlesource.com/platform/tools/base/+/studio-master-dev/build-system/gra[…]dle/internal/tasks/DeviceProviderInstrumentTestTask.java>

not without doing a fragile hack like
```task.outputs.withGroovyBuilder {
    setProperty("upToDateSpec", AndSpec.empty&lt;Task&gt;())
}```
afaik

You have to declare the `functionalTest` _compilation_ as a _associated with_ the main compilation:
```kotlin.target.compilations.named("functionalTest") {
    associateWith(kotlin.target.compilations["main"])
}```
The Kotlin plugin does that automatically for the `test` source set, but you have to do it manually for any other source set (e.g. testing suites)

does `compilations` exist outside of KMP?

ah okay, it exists on `KotlinJvmProjectExtension` too, but not on `KotlinProjectExtension`

`testFixtures` by default has the same problem, I guess it is an intended behavior, right?

I tried to do the same with `testFixtures` but no luck :shrug:

```kotlin.target.compilations.named("functionalTest") {
    associateWith(kotlin.target.compilations["testFixtures"])
}```

Do I need to do something special for getting plugin under test working?

```Test runtime classpath does not contain plugin metadata file 'plugin-under-test-metadata.properties'
org.gradle.testkit.runner.InvalidPluginMetadataException: Test runtime classpath does not contain plugin metadata file 'plugin-under-test-metadata.properties'```

```val testPluginClasspath: Configuration =
    configurations.create("testPluginClasspath")

dependencies {
    for (dependency in pluginUnderTestDependencies) {
        testPluginClasspath(dependency)
    }
}

tasks.withType&lt;PluginUnderTestMetadata&gt;().configureEach { metadata -&gt;
    metadata.pluginClasspath.from(testPluginClasspath)
}```

It was working on `test` source set, but fails on `functionalTest` one

```kotlin.target.compilations {
    val main by getting
    val testFixtures by getting {
        associateWith(main)
    }
    named("functionalTest") {
        associateWith(main)
        associateWith(testFixtures)
    }
}```
compiles fine for me with access to `internal` across source sets, the only problem is the IDE not recognizing it

you can use `@file:Suppress("INVISIBLE_REFERENCE", "INVISIBLE_MEMBER")` to bypass `internal` protection as well. the IDE won't help with auto-complete but it'll stop showing red errors

Wrt plugin-under-test-metadata:
```gradlePlugin {
    testSourceSets(project.sourceSets["functionalTest"])
}```

Looks like it is getting cached and it passes even when it should fail. I run from the IDE and it fails, but when running it via terminal it passes and the tests are not running. Should I config something more?

Indeed it only fails from IDE, from terminal even using `--rerun-tasks` it passes :thinking_face:

Looks like it was fixed alone, some weird cache I guess

You don't delegate to Gradle when running from the IDE? (assuming you're using some flavor of JetBrains' IDE, no idea how things work in other IDEs)

Yeah, that was the weird part, IDE uses Gradle and it was failing correctly but via terminal it was passing. But looks like it is fixed

To reiterate, whenever I modify avdl files, Gradle successfully determines that the code has changed and doesn’t fallback to the cache.

But for others, Gradle seems to think that the code is identical and simply hits the cache

try <https://docs.gradle.org/current/userguide/declaring_repositories.html#sub:centralized-repository-declaration> instead of a custom plugin

ow nice, that makes it better.. thank you

Probably not too far away, as rc-2 is already released.

That is what I thought, but it would be nice to understand if that is more like “2, 3 weeks” or “1, 2 months” :wink:

On the issue tracker you can see there will be a RC3
<https://github.com/gradle/gradle/milestone/225>

We issue GA release one week after the last RC without reported regression

Please try the RCs and report any problem

No problems with RC2 so far, thus the question :wink:

I don't think so, just register a new task and configure it like you need it.

```tasks.register&lt;DependencyUpdatesTask&gt;("myTask")```
Is this the correct API?

Yes, or if you prefer
```val myTask by tasks.registering(DependencyUpdatesTask::class)```

Especially if you need the task reference later on

Works like a charm. I have noticed a lot of .pom files has been downloaded while running the new task. So I conclude that the new task is not aware of the output of the original task. Is it possible that both task share same outputs? Should I even bother with this or is it for more experienced gradle user?

I don't think there can anything be shared, but that would be a question to Ben I guess

Could you link him, maybe he will have a look. But isn't it common in gradle that 1 Task produces an output and another task relies on it?

I don't know whether he is in this Slack, at least I cannot find him by his name.
But yes, it is common that one task uses the output of another task as input.
But that's not your situation, is it?
You have two sibling tasks that do the same task with different configuration.

Ah ok. Tbh I'm not sure if this is even a configuration because no properties are set:

```/*
  Versions configuration.
  Register new task to retrieve only stable versions.
 */
fun isNonStable(version: String): Boolean {
    val stableKeyword = listOf("RELEASE", "FINAL", "GA")
        .any { version.uppercase(Locale.getDefault()).contains(it) }
    val regex = "^[0-9,.v-]+(-r)?$".toRegex()
    val isStable = stableKeyword || regex.matches(version)
    return isStable.not()
}

tasks.register&lt;DependencyUpdatesTask&gt;("dependencyUpdatesStable") {
    rejectVersionIf {
        isNonStable(candidate.version)
    }
}```
That's all I have done.

Yes, this is still configuration :slightly_smiling_face:

ok in this case it makes sense that the output will be different and thus not sharable. Thanks Vampire, you are the best