Disable "Using classes instead of jar for compilation"?

Help/Discuss
1

“Using classes instead of jar for compilation” is causing me problems. I am moving from the java plugin to the java-library one, which seems to be the cause. Specifically referring to classes instead of jars for project dependencies when those projects define automatic Java 9 module names. A module that defines an explicit module-info.java and tries to require the module with an automatic name will fail because the automatic name is only known through the module’s jar file manifest.

I can verify that setting org.gradle.java.compile-classpath-packaging does resolve the issue, but I’d really prefer a way to disable that for the specific “importing” module. Is that possible?

FWIW, attempting to set org.gradle.java.compile-classpath-packaging in the project’s gradle.properties file does not work.

2

Funny, I have a similar request but the other way around.
I want it to be the classes directory and not the JAR file but can’t find a way to achieve that.

Here is what I have:

dependencies {
  val property = System.getenv("org.gradle.java.compile-classpath-packaging")
  println("\n!!!\nIs classpath packaging disabled: $property\n!!!\n")

  implementation(":otherModule")
}

which is a Spring Boot application. When I start my project, I can see that otherModule-0.0.1-SNAPSHOT-plain.jar is added to the classpath, which is not what I want. I want the classes and resources directory to be on the classpath instead.
That is, because I want to start another Spring Boot application and use the Spring DevTools to disable e.g. Thymeleaf caching, so I can hot reload and change view templates.
This is not possible, because the JAR doesn’t get updated immediately.

And by the way, the output of above snippet is:

Is classpath packaging disabled: null

So I too (for opposite reasons) would benefit from something like

dependencies {
  implementation(mapOf(
    "path" to ":otherModule",
    "classpath" to "filesystem/jar"
  )
}

or similar :wink: Is there a way?
I also tried developmentOnly, which also just added the JAR instead.

3

The Spring boot plugin disables the jar task, this should be fixed in 2.5:

As a workaround, just call

tasks {
    jar {
        enabled = true
        archiveClassifier.set("plain")
    }
}
4

This works in the sense that I now have a dependency on the classpath on

${projectPath}/build/libs/${projectName}-0.0.1-SNAPSHOT-plain.jar
                                                        ^^^^^- archive-classifier set: ✔️

I have not looked inside the JAR to check if it is the slim-jar
(in contrast to the fat-jar that I think the Spring-Boot task produces).
That may have fixed a problem I wasn’t aware I might have, well, thank you :wink:

However judging from the topic, it is still not what I wanted. I expected to have:

${projectPath}/build/classes/java/main
${projectPath}/build/resources/main

on the classpath instead of the JAR (fat or slim).

Where as the thread initiator seems to have the exact opposite problem and wants to have the JAR as a dependency. So in that regard, I don’t see that it actually helped.

5

Oh gosh, after re-reading the sentence in the documentation:

A feature of the java-library plugin is that projects which consume the library only require the classes folder for compilation, instead of the full JAR.

I realized that this does not apply to me, because I have only those enabled:

  • org.gradle.api.plugins.JvmEcosystemPlugin
  • org.gradle.api.plugins.ReportingBasePlugin
  • org.gradle.api.plugins.JavaBasePlugin
  • org.gradle.api.plugins.JavaPlugin

neither java-application nor java-library where the documentation explicitly states, that what I want is a feature of that the java-library plugin.

I am sorry, as I started digging into the problem it looked like it was similar (but the other way around) than the initial question. It seems that’s not the case but it is a problem with how I set up my multi-module build.
I would still love to have it work declaratively the same way, but I guess that’s a different thing than the initial question. Sorry for the noise…