Any idea what might the issue is: ```Execution fa...

# gradle

[Ahmed Riyadh]

Any idea what might the issue is:

Execution failed for task ':moduleName:compileKotlin'.
> Could not resolve all files for configuration ':moduleName:detachedConfiguration1'.
  > Failed to transform JarName-0.0.1.jar to match attributes {artifactType=classpath-entry-snapshot, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}.
   > Execution failed for ClasspathEntrySnapshotTransform: /Users/UserName/Developer/projects/ProjectName/build/libs/JarName-0.0.1.
     > Check failed.

It happens when I have code in the root project src/main/kotlin (not a module or sub-module) in the root project, and then I have a Gradle module that implements the root project, for example, let's say you have moduleName Gradle module, the issue might be with some of the configurations of Gradle but it happens even after disabling all of them.

The `settings.gradle.kts`:

include(":moduleName")

The dependencies of the build.gradle.kts of the moduleName:

implementation(project(":"))

I tried using enableFeaturePreview("TYPESAFE_PROJECT_ACCESSORS") but it's the exact same with type-safety

I tried doing this before and it worked but not sure what I'm missing this time.

Thank you.

[Vampire]

Did you follow the error advice and run with --stacktrace or optimally --scan?

[Ahmed Riyadh]

Already did, I tried with -i (same as --info)
and it didn't give me any related info, with --stacktrace it give me too much info (Slack won't allow me to send a long message)

Caused by: java.lang.IllegalStateException: Check failed.

[Vampire]

Then attach it as file or use a pastebin service like gist.github.com or pastebin.com.

Or just share the build --scan URL

[Ahmed Riyadh]

https://gradle.com/s/uvnrlevgtu44q

[Vampire]

I'd say it chokes on /Users/ellet/Developer/projects/minecraft-sync/build/libs/MinecraftSync-0.0.1-experimental.jar not existing for some reason when it expects it to exist.

[Vampire]

And it does not exist as the :jar task was skipped

[Ahmed Riyadh]

It might be because I'm depending on the root project instead of creating it's own module and then depend on it, but I'm pretty sure I did this before with no issues

[Vampire]

Skip reason'Task is enabled' not satisfied

[Vampire]

So you probably set enabled = false for the jar task on the root project

[Ahmed Riyadh]

I did:

// Disable the normal jar task as we will use the one from Shadow plugin
tasks.jar { enabled = false }

Because I'm using Shadow jar

[Ahmed Riyadh]

But I already tried disabling all the configurations and the same issue happened

[Vampire]

Well, you declare you depend on the jar but you disable the jar task => boom

[Vampire]

There might be a feature variant for getting the shadow jar instead. Have a look at the result of :outgoingVariants task

[Ahmed Riyadh]

It's like you said, the issue is with

tasks.jar { enabled = false }

The reason why it worked before with this code snippet because it already build the jar in build/libs and I didn't change the version, doing ./gradlew clean or removing the build folder will make the issue happen again.

[Ahmed Riyadh]

I'm not sure what to do though, by default the task jar that come with Gradle doesn't include the dependencies, so I'm not sure how the other module will get that jar to working, and I still want to disable this task jar because I don't want two jars in the build/libs as this would make it more confusing and I have other reasons, have you used Gradle Shadow plugin before?

[Vampire]

I avoid it wherever possible as I greatly dislike those bad-practice fat jars.

But as I said if you are lucky it adds a feature variant to get the fat jar. I also told you where to check which variants are provided.

[Vampire]

I avoid it wherever possible

And especially never for anything something else depends on. If at all needing to build fat jars, then only at the end of the dependency chain

[Ahmed Riyadh]

> I avoid it wherever possible as I greatly dislike those bad-practice fat jars.
If you want to build a cross platform script that work without building it for each platform and it has everything the script need to run without installing anything extra other than Java JRE, I'm not sure you would have that many of options

The problem of needing different platform (macOS, Linux and Windows) can be easily solved with CI, but still the users are required to install something differently based on the OS

[Vampire]

Sure you have.
If you build such a bad-practice fat jar, you "just" repackage the jar contents into your final jar.
You could as well build a proper distribution that just contains the jars like the application plugin does it.
If that would be platform dependent, so would be your fat jar.

[Ahmed Riyadh]

I managed to solve it thanks to you, I removed the tasks.jar { enabled = false }
And changed the output of the fat jar provided by shadow jar plugin to somewhere else so the CI doesn't provide the jar that is built by Gradle which is used by other modules, but I still doesn't understand why this is a solution, when I add implementation of module A in a Gradle module B, I can access to all the libraries of of module A in module B, if it depends on the Jar that is built by Gradle then how it can access the libraries? The library built by Jar doesn't include the libraries and it's very small and usually when running an application with that jar built by Gradle, it will give you ClassNotFoundException if you use libraries, this is why we use fat jar.

[Vampire]

Of course the jar does not find the classes.
As I said, you would normally using something like the application plugin to build a proper distribution that contains your jar, your libraries, anything else you configure, and generated start scripts that put everything together when running.
https://docs.gradle.org/current/userguide/application_plugin.html

[Ahmed Riyadh]

Yes but I'm wondering if Gradle use that jar then how it's possible to use the Gradle libraries of the included module/project? Does it store metadata in the jar about the libraries for example?

[Vampire]

No, of course not. But that's what a build tool is for amongst other things. To resolve transitive dependencies where needed. If a library is published, the information is in the Gradle Module Metadata file and / or POM and / or Ivy file. The same information is of course available for project dependencies within one build.