GoogleCloudPlatform / app-gradle-plugin

The library has moved to https://github.com/GoogleCloudPlatform/appengine-plugins/tree/main/app-gradle-plugin

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add Support For Thin Jars and Entrypoint (using Spring Boot)

h4t0n opened this issue · comments

It could be useful to avoid to use the fat jar (from bootJar task), using instead the gcp app.yaml entrypoint. In this way the upload of all the dependencies should occur only the first time. An attempt was made by Jhipter in jhipster/generator-jhipster#10420.

commented

FYI: @saturnism, @ludoch, @SudharakaP
So the current "thin jar" support is just for helping users who have correctly defined a thin jar deplyoment with proper Class-Path entries.

I would expect a user to skip the bootjar task and instead properly create the thin-jar deployment:

bootJar {
  // baseName = 'gs-spring-boot' // use this down in the jar task
  // version =  '0.1.0'
  enabled = false;
}

task copyLibs(type: Copy) {
  into "$buildDir/libs/"
  from configurations.runtimeClasspath
}

jar {
  enabled = true;
  baseName = 'gs-spring-boot'
  version =  '0.1.0'

  manifest {
    // add a main class (usually taken care of by springboot plugin - in bootjar case)
    attributes("Main-Class": "hello.Application")
    // this line correctly adds the classpath to the jar manifest
    attributes(
      "Class-Path": configurations.runtimeClasspath.collect { it.getName() }.join(' '))
  }
  dependsOn copyLibs
}

so when you run

./gradlew appengineStage

You will see a project in the staging directory configured as a "thin-jar" with included dependencies.

HOWEVER it seems like what users are asking for is: auto expand out the fat jar.

I personally would not like the plugin to do this:

I think it has its advantages:

  1. We can probably deal with static content better (for CDN).
  2. It's less mental effort on the user.

The disadvantages exist too:

  1. Cannot launch using java -jar anymore
    1. this means the launch loses any context included in the MANIFEST.MF

^ Now we've done something like this in jib: but more tightly coupled with the build system. It's not inconceivable to build a plugin that does all this for the user, but I expect the spring team to handle that.

I think, having ability to specify a path in the JAR to extract, would help w/ the static content.

commented

@saturnism we would probably still need to populate the static content correctly in the app.yaml?

yes :(

close as obsolete.