-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Add Support For Thin Jars in GAE #10420
Conversation
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
As per my discussion in GoogleCloudPlatform/app-maven-plugin#399 we need to change this approach. I will refactor the current pull request soon. 😄 |
@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. |
/cc @ludoch quick que
|
Does these clarify your questions? 😄 |
@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? |
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. |
With reference to #10533, I've just added the -Xmx value for appengine entry-point. |
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? |
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.
Sure. 😄 |
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. |
While working on #10345, I've come across some bugs and fixed them as well. 😄 Close/Open for tests |
…Cloud SQL - this makes sure the correct port environment variable is passed whether the user chose to use cloud sql or not.
@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? |
@saturnism: Hey, Yes of course it can be merged and I think it's better to be merged
separately from any micro-service related logic. I didn't put any
micro-service related code into it.
I am working/thinking on the micro-service support. I think we are close,
have to figure out some things related to the jhipster registry deployment
and stuff. 😄
…On Wed, Dec 11, 2019, 11:49 AM Ray Tsang ***@***.***> wrote:
@SudharakaP <https://github.com/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?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10420?email_source=notifications&email_token=AC64D7NF7MXOFBQKEJ25HLDQYE745A5CNFSM4IW3BXJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGULHHY#issuecomment-564704159>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC64D7KJUTW43E2XKRLT3Z3QYE745ANCNFSM4IW3BXJA>
.
|
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! |
@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. 😄 |
@SudharakaP : if I understand well, it's ready to be merged. |
@pascalgrimaud : Yes it's ready to be merged. @saturnism has indicated above that he'll give it one more try. 😄 |
Yes I saw it, so I'll merge it just before the next release, so in 1 week maybe |
@pascalgrimaud : Yes, no problems; please feel free to 👍 |
There was a problem hiding this 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) ?
@saturnism : I've done the changes. Thanks much 😄 |
/cc @PierreBesson @pascalgrimaud fyi - we think this is good to go! ready to be merged. |
@mraible : Thanks for merging 😄 |
Bug bounty claimed at; https://opencollective.com/generator-jhipster/expenses/12444 |
I tried to use GAE in 6.6.0 but gave errors. Is it fixed in 6.6.0? |
@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. 😄 |
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