Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Support For Thin Jars in GAE #10420

Merged
merged 38 commits into from
Dec 16, 2019
Merged

Add Support For Thin Jars in GAE #10420

merged 38 commits into from
Dec 16, 2019

Conversation

SudharakaP
Copy link
Member

@SudharakaP SudharakaP commented Sep 15, 2019

This adds support for unjar the "fat jar" within the staging folder, thus giving ability for users to fully leverage the GCP platform features.

Fixes #10362

  • Please make sure the below checklist is followed for Pull Requests.

  • Travis tests are green

  • Tests are added where necessary

  • Documentation is added/updated where necessary

  • Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed

SudharakaP and others added 11 commits September 14, 2019 11:35
Only adds to maven build; work in progress
A previous pull request incorrectly removes the com.google.cloud.tools when gaeCloudSQLInstanceNeeded is set to false

#10362
The new GAE with Java 11 builds on JAR; this has been done on the maven side.
A previous pull request incorrectly removes the com.google.cloud.tools when gaeCloudSQLInstanceNeeded is set to false
If this is not done the following error is created;

yntaxError: Multi-line double-quoted string needs to be sufficiently indented (16:14)
  14 |     datasource:
  15 |         type: com.zaxxer.hikari.HikariDataSource
> 16 |         url: "jdbc:mysql://google/mysql?cloudSqlInstance=abstract-block-253023:us-central1:testjhipster
     |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This adds Gradle side support for thin jars
@SudharakaP SudharakaP changed the title Add thin jar support gae Add Support For Thin Jars in GAE Sep 15, 2019
@SudharakaP
Copy link
Member Author

As per my discussion in GoogleCloudPlatform/app-maven-plugin#399 we need to change this approach. I will refactor the current pull request soon. 😄

@SudharakaP
Copy link
Member Author

SudharakaP commented Sep 17, 2019

@saturnism : I've made the changes and added ludoch's workaround to remove the original jar. I think we are good go ahead with code review and merging.

@saturnism
Copy link
Member

/cc @ludoch

quick que

  1. w/ this patch, we still retain the JAR file, and in addition we have the unpacked directory
  2. if i remove a resource/class from source, the unpacked directory will reflect that deletion as well?

@SudharakaP
Copy link
Member Author

SudharakaP commented Sep 19, 2019

@saturnism :

  1. As it stands currently, the JAR file is removed (not uploaded to GAE) as it's no longer useful since we unpacked it. Only the unpacked contents remain in staging directory.

  2. At deployment to GAE, the unpacked directory will reflect the deletion; each time you deploy the staging directory is rebuilt to reflect the new contents.

Does these clarify your questions? 😄

@saturnism
Copy link
Member

@SudharakaP thanks for confirming. Understood. It would be really nice if it was also able to retain the original JAR, but prob not easy to do do right now.

@ludoch @loosebazooka - perhaps more we can do on the plugin side to make this type of work flow much easier?

@SudharakaP
Copy link
Member Author

@SudharakaP thanks for confirming. Understood. It would be really nice if it was also able to retain the original JAR, but prob not easy to do do right now.

I think there's a slight misunderstanding here. So initially we have our original jar (we'll call it the fatjar). This fat jar is copied to the staging directory and then deployed by the appengine plugins. What we did is to unjar this fat jar within the staging directory (the original fat jar outside the staging directory is still there) and then tell appengine plugin to deploy. But appengine plugin when told to deploy not only deploy it but does the staging again. This copies the fatjar back into the appengine-staging directory. This already extracted fatjar within the staging directory is the only one that is deleted (using the workaround as suggested by ludoch). So to answer your original question the actual fatjar generated by spring boot remains within the target directory. Does this make sense? 😄

On another note what probably should be done to enhance the appengine maven and gradle plugins is to have an option to only deploy without doing the staging; or any means to get rid of the workaround to remove the fatjar in the staging directory. Furthermore the documentation use the term thin jar which probably gives a wrong idea where we can just upload a jar without any dependencies which I initially tried to do using spring-boot-thin-launcher which is the wrong approach.

@SudharakaP
Copy link
Member Author

With reference to #10533, I've just added the -Xmx value for appengine entry-point.

@saturnism
Copy link
Member

we shouldn't hard code Xmx here, since instances are different and heap size depends on the instance size.

/cc @ludoch @loosebazooka this is getting really hard to do a simple deployment in an optimized way. tbh, the plugin itself should do the JAR unpacking, and/or copy the dependencies in case of a thin JAR. I feel this is too much JHipster is doing and it's getting complex even if it's being generated.

@SudharakaP may i suggest let's focus on the microservices side of thing first while we figure this out separately?

@SudharakaP
Copy link
Member Author

SudharakaP commented Oct 10, 2019

@saturnism :

we shouldn't hard code Xmx here, since instances are different and heap size depends on the instance size. 😄

Agreed. But I was thinking we should set a default Xmx which is why I set it there. Anyhow I will revert that change since thinking about it again I think it isn't the most elegant.

@SudharakaP may i suggest let's focus on the microservices side of thing first while we figure this out separately?

Sure. 😄

@saturnism
Copy link
Member

A reasonable default would need to be dynamic. I.e., F1 only has 256M of runtime memory. Setting -Xmx to 512MB will cause the app to exceed the runtime memory very quickly. Let's table this as I discuss more w/ Ludo and Appu.

@SudharakaP
Copy link
Member Author

SudharakaP commented Nov 30, 2019

While working on #10345, I've come across some bugs and fixed them as well. 😄

Close/Open for tests

@SudharakaP SudharakaP closed this Nov 30, 2019
@SudharakaP SudharakaP reopened this Nov 30, 2019
@saturnism
Copy link
Member

@SudharakaP hiya! can this be merged for the initial support? we only supported monoliths at the beginning. microservices is harder, but we can discuss how to support that separately. wdyt?

@SudharakaP
Copy link
Member Author

SudharakaP commented Dec 11, 2019 via email

@saturnism
Copy link
Member

could i trouble you to dm me on twitter @saturnism ? happy to discuss some of that over hangout.

in the mean time, i'll give this one more try and let's merge it soon. thnx!

@SudharakaP
Copy link
Member Author

SudharakaP commented Dec 11, 2019

@saturnism : No problem. I didn't have twitter until recently. A few days back I created a twitter profile just to keep in loop with JHipster stuff. I am outside at the moment, but I'll dm you tonight for sure. 😄

@pascalgrimaud
Copy link
Member

@SudharakaP : if I understand well, it's ready to be merged.
Unless someone else can test and review it, I'll trust you and merge it for the next release !

@SudharakaP
Copy link
Member Author

@pascalgrimaud : Yes it's ready to be merged. @saturnism has indicated above that he'll give it one more try. 😄

@pascalgrimaud
Copy link
Member

Yes I saw it, so I'll merge it just before the next release, so in 1 week maybe

@SudharakaP
Copy link
Member Author

SudharakaP commented Dec 14, 2019

@pascalgrimaud : Yes, no problems; please feel free to 👍

Copy link
Member

@saturnism saturnism left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found last 3 things. 2 in the comment, but 1 more is a verbiage change that I can't add to the comment here:

Initialize a new Cloud SQL instance (Y/N) ? -> Use a Cloud SQL instance (Y/N) ?

generators/gae/templates/application-prod-gae.yml.ejs Outdated Show resolved Hide resolved
generators/gae/templates/pom-plugin.xml.ejs Outdated Show resolved Hide resolved
@SudharakaP
Copy link
Member Author

@saturnism : I've done the changes. Thanks much 😄

@saturnism
Copy link
Member

saturnism commented Dec 14, 2019

/cc @PierreBesson @pascalgrimaud fyi - we think this is good to go! ready to be merged.

@mraible mraible merged commit 7d21a02 into jhipster:master Dec 16, 2019
@SudharakaP SudharakaP deleted the add-thin-jar-support-gae branch December 16, 2019 03:00
@SudharakaP
Copy link
Member Author

@mraible : Thanks for merging 😄

@SudharakaP
Copy link
Member Author

Bug bounty claimed at; https://opencollective.com/generator-jhipster/expenses/12444

@Tonterias
Copy link

I tried to use GAE in 6.6.0 but gave errors. Is it fixed in 6.6.0?

@SudharakaP
Copy link
Member Author

@Tonterias : This ticket is for adding support for thin jars in GAE; which is completed in 6.6.0. If you see any specific errors, I would suggest opening a new issue with complete details or if it's a question use our gitter channel or stack overflow. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

App Engine Java 11 generator to create thin JARs
9 participants