5

Components

  • Spring Boot 1.4.3 (and have also tried with Spring Boot 1.5 RC1)
  • Java 1.8.0_112 on Mac OS Sierra
  • Gradle 3.3 / Maven 3.3.9
  • Simple Java web application configured with Spring Boot Gradle plugin (Same issue appears to be applicable to the Spring Boot Maven plugin as well)

Problem

Attempting to run the application via the likes of gradlew clean build bootRun or simply gradlew bootRun shows that the gradle/java process exits/crashes miserably without a hint. No further errors or logs are displayed other than:

"/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home/bin/java finished with non-zero exit value 1".

Running gradlew bootRun --debug however shows that the BootRun (an extension of Gradle's JavaExec) task seems to want to generate a VERY VERY VERY long Classpath entry that ultimately bombs the Java process.

The Spring Boot documentation specifies:

To run a project in place without building a jar first you can use the “bootRun” task

http://docs.spring.io/spring-boot/docs/current/reference/html/build-tool-plugins-gradle-plugin.html#build-tool-plugins-gradle-running-applications

But it doesn't seem like this method can work if the plugin is to generate such long classpaths.

Reproduce

This project here may demonstrate the issue:

https://github.com/apereo/cas-gradle-overlay-template

In the cas/build.gradle file, one could add a dependency to observe the behavior:

compile "org.apereo.cas:cas-server-support-json-service-registry:${project.'cas.version'}"

Diagnosis

The project contains the following dependency:

dependencies { compile "somewhere:something:somehow@war" }

This presents no issues at all to bootRun; however when any other compile/runtime dependency is added to the project, all dependencies transitive or otherwise are added to the classpath for bootRun to execute.

I did also try creating a "pathing" JAR with hopes that the plugin/Java might simply use the Class-Path entry in that JAR's manifest to run the web application and the classpath entry passed to the java command would be shortened as such. However, that did not make a single difference and java simply crashed again.

Note that running the web application as an executable jar with java -jar app.war works perfectly fine with all dependencies, etc.

Have others run into similar issues?

Misagh Moayyed
  • 4,154
  • 2
  • 15
  • 25

0 Answers0