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

Gradle Community

link to build-scan: <https://scans.gradle.com/s/oexvsmcnmyz6m/console-log?anchor=17069>

Besides that you should not start every build with "clean" (that was necessary with Maven builds as the are unreliable and non-reproducible), it is hard to guess without seeing your build scripts.

build.gradle

That's only a part of the picture.
There are various included script plugins.
Best would be if you can knit an MCVE (<https://stackoverflow.com/help/mcve>)

Btw. `assert System.properties["java.specification.version"] == "1.8" || "11" || "12" || "13"` will *always* be `true`.
You basically wrote `assert System.properties["java.specification.version"] == "1.8" || true || true || true`

can you pls suggest me the correct block of code here? Because I am confused with the above basically block.. What should have been the correct block of code here? help me understand..

What you have is in prose:

assert that
either `java.specification.version` is equal to `"1.8"`
or `"11"` is `true`
or `"12"` is `true`
or `"13"` is `true`

And according to Groovy truth rules, the last three are always `true`.

Actually, if you want a certain version for building your project,
I'd recommend you use the JVM Toolchains feature instead, so the Java version to
run Gradle is decoupled from the Java version used to build and run your code.

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

Question is how to fix the above warnings?

If this is your plugin, add the appropriate annotation; if it’s a 3rd party plugin, upgrade to a version that is compatible with newer Gradle versions.

thankyou <@U02S31Y7J2K> resolved it by updating the plugin version

Where is the code ? :johntravoltalookingaround:

Another issue you might bump into with lambdas is that some of them use invokedynamic starting with some version of Kotlin: <https://github.com/gradle/gradle/issues/17052>
But IIRC, that causes tasks to be not up-to-date, not `NoClassDefFoundError`

I typed it up, but then realized a repro project might be better, so I'm working on that (and naturally I can't repro it) :see_no_evil:

Here's a repro project showing a `NoClassDefFoundError` seemingly caused by a nested lambda that is referenced in bytecode but is not getting compiled to a class file.

If you run:

```cd plugin
./gradlew publishToMavenLocal
cd ../app
./gradlew tasks```
then you should see the failure:

```* What went wrong:
Com_eygraber_publish_gradle$2$1$1
&gt; Com_eygraber_publish_gradle$2$1$1```
To get it to work, edit `plugin/src/main/kotlin/com.eygraber-publish.gradle.kts` line 24 from:

```repositories {
  githubPackagesPublishing(
    owner = "eygraber",
    repo = repoName
  )
}```
to

```repositories.githubPackagesPublishing(
  owner = "eygraber",
  repo = repoName
)```
then run the steps above again and the task will complete successfully.

Whatever issue this is, looks like it happens when compiling the plugin. If you unzip `compiler-issue-plugin-0.0.1.jar` , you will not find a matching .class file for `Com_eygraber_publish_gradle$2$1$1`

What you can do is try to remove the precompiled script plugin support:
```plugins {
    `embedded-kotlin`
    id("org.jetbrains.kotlin.plugin.sam.with.receiver")
    id("java-gradle-plugin")
    alias(libs.plugins.publish)
}

samWithReceiver {
    annotation("org.gradle.api.HasImplicitReceiver")
}

gradlePlugin {
    plugins {
        create("com.eygraber-publish") {
            id = "com.eygraber-publish"
            implementationClass = "MyPlugin"
        }
    }
}```


The `kotlin-dsl` plugin does <https://github.com/gradle/gradle/blob/5d94aa68c0fdbe443838bb977080e3b9f273e889/subprojects/kotlin-dsl-provider-plugins/src/main/kotlin/org/gradle/kotlin/dsl/provider/plugins/precompiled/DefaultPrecompiledScriptPluginsSupport.kt#L117|a bunch of things> to support precompiled script plugins. I'd suspect something is lost there or there is some unfortunate interaction with the Kotlin compiler

By using "regular" (i.e. not precompiled) Kotlin plugins, you'll also save some time. See also <https://github.com/android/nowinandroid/issues/39>

&gt; remove the precompiled script plugin support
&gt; 
I have a feeling that will fix it as well, however I found a workaround that's much less involved (see the end of my previous message)

I'm going to file an issue for it, but I thought I'd put it here first in case anyone was already aware of the problem

&gt; By using "regular" (i.e. not precompiled) Kotlin plugins, you'll also save some time
&gt; 
These plugins are in a different project and are compiled into a separate artifact, precisely to solve the issue you linked :grin:

Share the link to the issue here when you have it so we can :star:

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

The question is whether it is a Gradle or Kotlin bug. We'll see.

The `project` method you call in there is not the same you call in the top level `dependencies` block. Use `project.dependencies.project(...)` and it should work

There's also an issue to hopefully improve on that

That doesn’t seem to work… the build script parses, but it doesn’t resolve my classes. I declared it like this:
```testing {
  suites {
    test {
      dependencies {
        project.dependencies.project(path: ':test-common', configuration: "testJar")
      }
    }
  }
}```
I’m not quite sure what that’s doing… how does that know to add the dependency to the `testImplementation` configuration? It looks to me like the equivalent of declaring it in the top-level `dependencies` block without a configuration.

You forgot the leading `implementation` , now you just create the project dependency but do not add it to the configuration you want to have it in.

Excellent, that’s the info I needed, thanks. For posterity, here’s the syntax that worked:
```testing {
  suites {
    test {
      dependencies {
        implementation project.dependencies.project(path: ":test-common", configuration: "testJar")
      }
    }
  }
}```
Now that I see the syntax, I understand your original comment and the scoping of the `project` method. Thanks again for taking the time to respond.

`&gt; Task :library:verifyReleaseResources FAILED`

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':library:verifyReleaseResources'.
&gt; A failure occurred while executing com.android.build.gradle.tasks.VerifyLibraryResourcesTask$Action
   &gt; Android resource linking failed
     ERROR:/Users/varmabhupatiraju/.gradle/caches/transforms-3/8e1dbca81dfad29f4aee913d13f7c843/transformed/core-1.7.0/res/values/values.xml:105:5-114:25: AAPT: error: resource android:attr/lStar not found.

this error i'm getting while running  `./gradlew assembleRelease`

`app/build.gradle`

```buildscript {
    //ext.kotlin_version = '1.6.0-RC2'
    ext {
        buildToolsVersion = "30.0.2"
        minSdkVersion = 21
        compileSdkVersion = 31
        targetSdkVersion = 31
        ndkVersion = "21.4.7075529"
        kotlinVersion = "1.4.32"
        kotlin_version = '1.4.32'
        dokka_version = '0.10.1'
    }
    repositories {
        google()
       mavenCentral()
    }
    dependencies {
        classpath('com.android.tools.build:gradle:7.1.2')
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlinVersion"
       // classpath "org.jetbrains.dokka:dokka-gradle-plugin:${version_dokka}"
        classpath "org.jetbrains.dokka:dokka-gradle-plugin:$dokka_version"
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
        classpath 'com.google.gms:google-services:4.3.10'
          classpath 'com.google.firebase:firebase-crashlytics-gradle:2.8.1'
        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
} ```

The plugin used for generating avro files is the following: <https://github.com/davidmc24/gradle-avro-plugin>

Is there any workflow that you guys can think of that could potentially cause this to happen?

look at the task from that plugin that generates the files you want and takes the .avdl input you're talking about and look for obvious issues first.

build scans can help. If you are a GE customer, you can do a build comparison between failed and successful builds

Yes, from time to time it happens that the Grand state gets confused. It then thinks tasks are up-to-date even though they are not, leading to very unexpected behavior.

<@URQ797WRW> is there a solution for this?
I’m thinking of maybe purging our caches on GitLab runners at midnight and running a full build afterwards

It happened occasionally here and I did not find any clue as to what is wrong or how to reproduce.
If I see it happen, I usually just delete `&lt;GRADLE_USER_HOME&gt;/*` and `&lt;root project&gt;/.gradle` and then it works again.
But that's just the mega-hammer to get the colleague up and running again quickly.

I haven’t been able to reproduce it either.
I think I’ll purge the cache on my runners on the weekend so that I can have some proactivity.

Glad to know I’m not the only one, thanks for your insights

Actually, I've never seen it on CI, but that's probably caused by me only running clean builds on there as on CI I prefer reliability over speed. :slightly_smiling_face:

Interesting, we actually opted against running `clean` on CI.

Well, like always, every decision has its pros and cons :slightly_smiling_face:

our CI costs would spiral out of control if we didn't use build cache in that environment. it's absolutely critical

Quite possible, we have TeamCity on-premise, so costs do not really differ.
And besides that, I more meant incremental building.
Reusing a build-cache created from a clean build should imho be fine regarding reliability.

I see this statement in <https://docs.gradle.org/current/userguide/common_caching_problems.html> which is pretty much the issue we’re having but there’s no solution for it on that page.

Are there any cons to purging our Gradle cache in our runners at midnight and attempting to rebuild a “clean” cache promptly afterwards? I’m considering it to be a silver bullet

The solution to that described problem is, to not implement buggy tasks, or not use buggy tasks, or at least work-around-fix them by adding the inputs it uses.
In the cases I meant the tasks implementations are fine though.

That's not a Gradle question.
Your code exited with exit code 1.
Scroll up to see why it your program printed why or otherwise debug your code to find out what is happening.

Hi Jean-Michel
All Build Scans sent to <http://scans.gradle.com|scans.gradle.com> need to be activated. This is because there is no permission model there, at least for now, and we need a way to associate a Build Scan to a user for “ownership”. Now, if you tick the “Remember me” box when you activate a Build Scan, and use the same browser again when accessing an unactivated Build Scan later on, then “auto-activation” will kick in and auto-activate that new Build Scan for you. This works for a month before manual activation steps are required again. If you use another browser to activate a Build Scan, the activation process kicks in.

ah ok, the auto-activation is simply valid for a month. thanks

yes, it’s cookie-based with a 1 month expiration period

<@UUNHNUUBH> In practice though I had to through the `Active your Build Scan` processus 6 times in the last month
including today, yersterday and two days ago.
I am always using the same Firefox for macOS browser on the same iMac computer

I don't see a cookie that expires on September 5th

=&gt; solution was to clear all cookies because old ones were there (they should have been removed but the deletion logic somehow didn’t work)

Hi :wave: You'll increase your chances of getting an answer by reformatting your message. I know slack is painful sometimes but codeblocks are triple backtics

Besides that, you might wand to try something like
```./gradlew publishAllPublicationsToGitHubPackagesRepository```

You can get the full list of tasks with
```./gradlew tasks --all```

sounds like some funky classloading manipulation is going on to get `java.lang.Class.getEnumConstants()` and NoClassDefFoundErrors.  Have seen cases where plugins assume every run is a clean environment, which isn’t the case with the Gradle Daemon (by design), resulting in classloader pollution / corruption.

I'm rewriting some bytecode so the failing `getEnumConstants` is somehow expected at this point. What caught me off guard is that until I thought about stopping the daemon I had no clue at all what it could be

First crash I didn't have `--stacktrace` so I guess it was silently recorderd. Second crash got me `NoClassDefFound` , which was actually misleading as the class was there

gotta love classloaders.  :face_with_rolling_eyes: Depending how they are implemented, the behaviour for subsequent failures could be different (for example, they may have a negative cache of classes that aren’t found or could not be loaded).

Almost all cases of `NoClassDefFoundError` I've seen so far were follow-up problems after some static initializer threw an error as indeed JVM does not try to load the class again after initialization failed but throws `NoClassDefFoundError`, not to be confused with `ClassNotFoundException`.

Expected.  Dash, underscore, and dot are separators, resulting in the same accessor name.  You could have the generator add some suffix if the artifact ends with a separator - or fix the unusual naming convention of an underscore suffix (perhaps a proper qualifier is needed).

&gt; Aliases must consist of a series of identifiers separated by a dash (`-`, recommended), an underscore (`_`) or a dot (`.`). Identifiers themselves must consist of ascii characters, preferably lowercase, eventually followed by numbers.

I'm actually surprised it works with sepeartor at the end.
I'd almost expected that to be a naming violation.

Isn’t there a difference in what is allowed in aliases in Kotlin DSL versus Groovy DSL?
It’s been a while since I looked at it, but I recall the Kotlin DSL being a bit more forgiving in the names.

I'd wonder if there were, that would be majorly confusing

indeed.  the rules for aliases are clearly <https://docs.gradle.org/current/userguide/platforms.html|documented>, with no distinction between Kotlin &amp; Groovy.

Ahh, looking at my project, I was thinking of an alias oddity for plugins that we ran into before moving to a version catalog when using something like `ext.libraries`
There were nuances in plug in naming before then that would throw an error of `argument list must be exactly 1 literal String or String with property replacement`

I am migrating my Java projects from Maven to Gradle. I am using SureFire plugin with TestNG to pass in a custom <https://javadoc.io/doc/org.testng/testng/latest/org/testng/IInjectorFactory.html|IInjectionFactory> to do some custom dependency injection
```         &lt;plugin&gt;
               &lt;groupId&gt;org.apache.maven.plugins&lt;/groupId&gt;
               &lt;artifactId&gt;maven-surefire-plugin&lt;/artifactId&gt;
               &lt;version&gt;2.22.2&lt;/version&gt;
               &lt;configuration&gt;
                   &lt;properties&gt;
                       &lt;property&gt;
                           &lt;name&gt;dependencyinjectorfactory&lt;/name&gt;
                           &lt;value&gt;customimplementationclass&lt;/value&gt;
                       &lt;/property&gt;
                   &lt;/properties&gt;
               &lt;/configuration&gt;
           &lt;/plugin&gt;```
Is there an equivalent option for <https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/testing/testng/TestNGOptions.html|useTestNG> in Gradle?

It looks like the answer is obviously no, so I think I'll just use a patched gradle

If scaladoc isn't run in a forked process you could try to set gradle jvm options via `org.gradle.jvmargs` (e.g. in project's `gradle.properties`), see <https://docs.gradle.org/current/userguide/build_environment.html>

Unfortunately it is run in a forked process, I can see the 'Started Gradle worker daemon... with fork options ... { ... maxHeapSize=1G, jvmArgs=[], keepAliveMode=DAEMON }

Setting org.gradle.jvmArgs was my first hope, unless there is a way to force gradle to not make a worker, I would definitely be OK with that if possible

atm, I'm looking at just adding to <https://github.com/gradle/gradle/blob/master/subprojects/scala/src/main/java/org/gradle/api/tasks/scala/ScalaDoc.java#L228>, we already have a patched gradle on account of another issue, so another patch won't hurt I suppose.

ah, if it's a fork isn't `ForkOptions` or subclass accessible as part of the task configuration?

I don't think so, think this is a bit of a blind spot.

If we look at <https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/scala/ScalaDoc.html> neither it or its parents have anything appropriate

they seem to use workerexecutor and don't expose much unfortunately

and i guess you already tried adding `-Xss...` to the additionalParameters without `-J`?

Yeah I tried, if you do that gradle effectively ends up trying to invoke

```scaladoc -Xss64m ```
which results in

```scaladoc error: bad option: '-Xss64m'```
if you read scaladoc -help, you would think -J would do it, but if you just normally run

```scaladoc -J-Xss64```
you get the expected
```The Java thread stack size specified is too small. Specify at least 180k```
while if you pass this in to additionalParameters, it goes through silently, so it seems like (and from reading the code it makes sense), this -J-Xss won't do anything for scaladoc in the gradle case

Maybe there's something reflective I can do, but I don't feel especially confident with how that looks with respect to Gradle stuff.

unfortunately I'm not familiar with Gradle's Scala tooling, last time I used Scala with Apache Maven, so ideas above were just generic thoughts

No worries, thank you for the ideas. I'm really not hopefuly for this one, I think I understand the Gradle code well enough to say this one's not happening, it won't be so bad to just patch this one file.

Example of such a script here:

<https://github.com/jmfayard/my-kotlin-scipts/blob/main/scripts/goto.main.kts>

I wouldn't assume that error is related to that code

if I comment the plugin out
```plugins {
    //id("org.scijava.catalogs")// version "31.1.2"
}```
is gone

so I assume, that's the right way to import it

Unless I'm still too sleepy to look properly, I'd say so, yes

I opened an <https://github.com/gradle/gradle/issues/21455|issue> at the end

Precompiled script plugins are a great way to go, however they do add some build overhead

Precompiled scripts are the way when you want to build reusable parts! <@U021PMD2TL4> is right about the overhead; they are slow to compile, but they are cached; if you can keep the cache around, compiling them is a rare occurrence.

Besides that `apply from` still works with Kotlin DSL, you just do not have the type-safe accessors.
But yes, with both Groovy and Kotlin DSL the better way is to use precompiled script plugins.

<@URQ797WRW> that was exactly what I first hit when trying to simply break the script into smaller files. I'll then go the route of setting these up as PSPs. Thank you all for the input, very much appreciate it.

Heyo! Will Scala 3 be supported by Gradle "out of the box" without hacky and external implementations?

You use component metadata rules to fix attributes / variants / dependencies / ...

i read those but I am not sure how to pick out the variants I want.  The docs say to use `all` or `withModule` but I am not sure how to differentiate to add the metadata since AGP is making  the components

do you have a sample or know how to get info about the component after its been created?

Oh, I think I misunderstood.
I thought on the consumer side.
But you mean on the actual producer side.

I have no idea how the AGP does it, as I'm not into Android dev so far.
But I guess it declares consumable configurations for those variants.
And you probably have to add disambiguating attributes to those configurations.

If I understand correctly , I guess the other way would be to create another submodule such as `protocol` that generates the code and then have your `rest-app` and `service-client` depend on `protocol`

well, i want to generate two separate code bases, with different generator configurations from the same api spec definition file

It is a checked-in file, not something generated by the build, right?

Why don't you just reference the file from both projects and have their own generate tasks each?

i can, but what's the best way to reference a single file across two modules? just put it in the parent and have a file system ref? "../../MyApiSpec.yml" etc?

we make it available as a publication artifact, so other modules can just have a project dependency on the spec

so, i guess that means i need a 3rd module just to hold the api spec?

`api-model` already publishes a bunch of classes, that would conflict with the classes generated into `service-client`

Not necessarily. If it fits semantically into one of the existing modules, you can just make a feature variant that publishes that file, or of it is just for usage within the build, but not for consumption by downstream projects, you can also just make a consumable configuration that you depend on.

ahh, a consumable configuration probably makes sense

I’m struggling to figure out the right gradle encantation for sharing the ApiSpec file between two projects.

project `a`:
`src/main/resources/static/apispec/ApiSpec.yaml`
`build.gradle.kts`
```val apiSpec: Configuration by configurations.creating {
    isCanBeResolved = false
    isCanBeConsumed = true
}


artifacts {
    // the build path resulting from (i assume) result of `processResources`
    add("apiSpec", file("build/resources/main/static/apispec/ApiSpec.yaml"))
]
openApiGenerate {
    inputSpec.set("src/main/resources/static/apispec/ApiSpec.yaml")
   // configure code generation into project a ...
}
configure&lt;SourceSetContainer&gt; {
    named("main") {
        java.srcDir(openApiGenerate.outputDir.get())
    }
}

tasks.withType&lt;JavaCompile&gt;().configureEach {
    dependsOn(tasks.named("openApiGenerate"))
}```
project `b` (consumes ApiSpec from `a`):
`build.gradle.kts`
```val apiSpecConfiguration by configurations.creating {
    isCanBeConsumed = false
    isCanBeResolved = true
}
dependencies {
    apiSpecConfiguration(project(path=":a", configuration="apiSpec"))
}
val apiSpecFile = apiSpecConfiguration.incoming.artifacts.artifactFiles.singleFile
openApiGenerate {
    inputSpec.set(apiSpecFile.absolutePath)
   // configure code generation into project b ...
}
tasks.withType&lt;JavaCompile&gt;().configureEach {
    dependsOn(tasks.named("openApiGenerate"))
}```
on a clean build i now get:

```* What went wrong:
A problem was found with the configuration of task ':b:openApiGenerate' (type 'GenerateTask').
  - In plugin 'org.openapi.generator' type 'org.openapitools.generator.gradle.plugin.tasks.GenerateTask' property 'inputSpec' specifies file '/Users/me/projects/myproj/a/build/resources/main/static/apispec/ApiSpec.yaml' which doesn't exist.

    Reason: An input file was expected to be present but it doesn't exist.

    Possible solutions:
      1. Make sure the file exists before the task is called.
      2. Make sure that the task which produces the file is declared as an input.```
what is the proper way to declare that consuming `a` configuration `apiSpec` depends on `processResources` to copy the file into build? or should i just add the file from the `src/` path into the artifact as that will _always_ be present (there’s no post-processing)?

As you use a plain path declaration and not some task output, you have to tell Gradle manually which task generates the file using
```add("apiSpec", file("build/resources/main/static/apispec/ApiSpec.yaml")) {
    builtBy(tasks.processResources)
}```
Or, as you said, just use the source path, that is also what you use to generate the code in `a` so would probably be more consistent.

the above (including builtBy) results in the same error

using the one in src/main/resources like:
```artifacts {
    add("apiSpec", apiSpecFile) {
        builtBy(tasks.processResources)
    }
}```
seems to work fine (though, not really reliant on processResources but :shrug: )

Hm, would have to play with it. :man-shrugging: 
But if you use the source file, remove the `builtBy`.

make sure your packaging keeps the `.kotlin_module` files

I’ve just been using the most basic configuration of: <https://github.com/vanniktech/gradle-maven-publish-plugin>

Is this something I would configure myself or should the plugin be doing it?

you’re right though, came across this issue <https://issuetracker.google.com/issues/64435479>

perhaps running in a JDK older than Java 11?  It’s recommended to use the  Java toolchain feature in Gradle to separate the JDK/JVM running Gradle from what is needed to compile the code.

what im confused with is that my build is successful but its not compiling

the error above shows the build failing to compile.  Please elaborate on the specific issue.

its my first time using java so am not sure what the error exactly is, whenever I run the application it just says
```Execution failed for task ':api:compileJava'.
&gt; invalid source release: 11

* 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.```


that’s a build failure.  add something like this to build.gradle:
```java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(11)
    }
}```

```
Error: A JNI error has occurred, please check your installation and try again
class has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601)

Process finished with exit code 1```

you have an older version of Java installed on your machine.  Install Java 11+.

alternately, explicitly choose Java 11 when running the application.

It isn’t clear from the docs or Gradle src that `whenTaskAdded` works on previously added tasks, opening the door to a timing issue.  While not related, `whenTaskAdded` is anti-lazy - eagerly realizing all tasks.

Perhaps the eagerness is related - that could force realization of all tasks before you expect that to occur.

Thank you for all this info, then if it is anti-lazy I guess it is not recommended to be used, so I would not try to fix this issue.

`resources` as in src/main/resources?  what does “explicit definition” mean?  Please explain the problem you are trying to solve and what appears to not be working.

Correct. By explicit definition I attempted to make use of `include` inside the build task. Basically the problem I am having is that files inside of *src/main/resources* are not being shaded into the JAR upon compilation.

what does your shading gradle task configuration look like?

Plain shadowjar quite frankly. Never had this issue before, but the last time I used Gradle was version 6.

ok.  are the resources in the jar itself (before shadowing)?

They're not. I tried compiling with the default task as well.

ok, so this isn’t related to shadow if they aren’t in the pre-shadow jar (presumably the output from `jar` task).  That’s all pre-configured as part of the java plugin - are there any configuration changes to sourcesets, etc?

Right. Nothing out of the ordinary from what I can see:

```plugins {
    scala
    `java-library`
    id("com.github.johnrengelman.shadow") version("7.1.2")
}

repositories {
    mavenCentral()
}

dependencies {
    implementation("org.scala-lang:scala-library:2.13.7")
}```

…and when you run `jar` , are the resources where expected?

The resources are absent no matter what I try. :thinking_face:

odd.  resources are in src/main/resources?

perhaps try running `jar` with `--clean --no-build-cache`

oops.  `clean` is the task, not an argument.  `./gradlew clean jar --no-build-cache`

is there scala source to compile in src/main/scala (and/or java source in src/main/java)?

ok.  run with `--info` - look at the `processResources` task (and other tasks) to see if they run.

`Output property 'destinationDir' file C:\Users\Oliwer\Desktop\dev\jvm\scala-loader\lib\build\resources\main has been removed.`

I mean `processResources` does indeed run as expected, it also exports all resource files into *build/resources/main*.

does `jar` run as expected and create a .jar file?  iirc in `build/libs`.

Yes. The JAR that is exported just does not consist of the resource(s).

so we have resources from `processResources` but not from `jar` (and of course missing downstream for shading)?

Yes, `processResources` does export the files into the directory of *build/resources/main* but they're not included in the jar itself when `jar` is ran, if that makes sense. :thinking_face:

odd.  any special configuration for `jar` beyond the defaults?

No. The build file I sent above is all I've got, really.

what are examples of some of the resources?

hmmm.  was wondering if they overlapped with some of the magical default excludes, but yml doesn’t.

It's a really odd situation tbh; I haven't been tied up with this using Gradle before, but that was with version 6.2 and I'm not sure if that has anything to do with it.

unlikely.  jar stuff is pretty straightforward.

This is still an issue for those who wonder. ^

Is this a project you can share? If not, can you create a minimal reproducer? Or in a pinch, is there some (sanitized/anonomyzed) debug log you can share? There's not a lot of information to go by, right now.

Excuse the late response, Niels. I actually got it working somehow by *downgrading* to *6.2*; now there does not seem to be a single issue what so ever.

that will probably just make the problem worse in the future though, as the gap will just become bigger :thinking_face: so it's probably a good idea to keep digging

That's true. I can back up the project and go back to version 7 to do some more digging.

Okay so hilariously enough, I found out the issue and it had nothing to do with Gradle what so ever... Initially (using v7), I attempted to decompile the JAR to see if the resource(s) were a part of the contents bundled - in this case they were not cause it filtered out anything but java files (ofc). When I switched over to v6, I attempted - at the same time - to view it over a ZIP archive without thinking much of it and to my surprise it was there. Sorry for the trouble people, I was just a victim of _my own stupidness_.

This is not a gradle issue. The error message clearly indicates an issue with android signing and more specifically failure to create a keystore.

perhaps this can be of interest: <https://stackoverflow.com/questions/47310006/android-studio-failed-to-create-keystore>

<@UMG417LGH> Thank you for your effort :pray:

Another thing to mention: I've also tried only adding the fixtures.jar however the helper class has a dependency on flyway, therefore when using it in my other project I receive a class Not Found error. That's why I'm trying to pack the whole module (so that I have access to sql files and dependencies).

if you simply publish to maven, gradle will publish the test fixtures as its own artifact by default, along with metadata about dependencies (as usual)

hey ! I've just tried to publish it to my local maven repo and it worked. however, there's still the issue of my flyway migrations. now it does indeed see the flyway dependency but it cannot see the location of the migrations in the filesystem. any suggestions ?
edit: thanks for taking the time to answer !

so basically, is there anyway to also ship the folder with the sql migrations so that the helper class can still see them ?

extra files are usually distributed as resources (eg `src/main/resources/*`) but I don't know details about flyway

while my question certainly drifts a bit off topic, I still think it's in test-fixtures scope. let me rephrase: if I'm hardcoding a file path in src/testFixtures that points to resources (outside src/testFixtures *but gets packaged in the jar*) will classes from testFixtures have access to that ? really sorry in advance if my understanding is not correct

no, not by *file* path. you can access it by resource name though

thanks for all the answers. I did manage to pass the file path by including "classpath:" in front of the string

Are you overriding the trust store? If not, the <https://github.com/gradle/gradle/blob/53dfb3a1292c5b07ede910d93e33fe9f0bf30ba9/subprojects/resources-http/src/main/java/org/gradle/internal/resource/transport/http/DefaultSslContextFactory.java#L190-L197|defaults should be here>.

He is using a custom trust store and an ancient Gradle version, or that error would not happen like that.
He uses either Gradle 5.2 or 5.3 and has `<http://javax.net|javax.net>.ssl.trustStore` set to the value `cacerts`.
This causes to search for the file `cacerts` in the current working directory where it is not found and this error is displayed.

Yes i'm using Gradle 5.2.1. Which file can i find this '`<http://javax.net|javax.net>.ssl.trustStore`' and would this error be solved if i set the value to the correct path?

I'd gess you have set it in `gradle.properties` or `~/.gradle/gradle.properties` but it can also come from some environment variable, or from custom distribution, or command line, ...

<@URQ797WRW> Thanks for the help!! Wasted a full day yesterday and couldn't figure it out but this did the job.

<https://services.gradle.org/versions/|https://services.gradle.org/versions/>

`--warning-mode=fail` will ensure you don't miss any deprecation warnings (by making them fatal)

<@U019L3NM4PK> can the warning mode be set in gradle.properties?

`--warning-mode=fail` seems to be only option for now. Just making sure the project works without ay other issues

<@U0383QKNG3C> This might help <https://stackoverflow.com/questions/54619731/add-warning-mode-all-command-line-argument-in-android-studio>

Is there an expected release date for gradle 8?

No due date but you can follow the milesones here <https://github.com/gradle/gradle/milestone/164>

Does this help? <https://docs.gradle.org/current/userguide/dependency_downgrade_and_exclude.html#sec:enforcing_dependency_version>