Closed h4t0n closed 2 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:
The disadvantages exist too:
java -jar
anymore
^ 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.
@saturnism we would probably still need to populate the static content correctly in the app.yaml?
yes :(
close as obsolete.
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.