GoogleCloudPlatform / app-gradle-plugin

The library has moved to https://github.com/GoogleCloudPlatform/appengine-plugins/tree/main/app-gradle-plugin
Apache License 2.0
153 stars 40 forks source link

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

Closed h4t0n closed 2 years ago

h4t0n commented 5 years ago

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 https://github.com/jhipster/generator-jhipster/pull/10420.

loosebazooka commented 5 years ago

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.

saturnism commented 5 years ago

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

loosebazooka commented 5 years ago

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

saturnism commented 5 years ago

yes :(

JoeWang1127 commented 2 years ago

close as obsolete.