Assigned
Status Update
Comments
ba...@google.com <ba...@google.com>
su...@google.com <su...@google.com>
ab...@gmail.com <ab...@gmail.com> #2
I'm in the same position. Support for Java8 is coming to an end for GAE standard but the documentation for Google Cloud Endpoints that my project uses indicate it runs only on Java8. I'm happy with using the bundled services for all the other stuff for now, but I don't see the immediate path to keep the Google Cloud Endpoints working and supported.
There's an indication that GAE standard 2nd generation should be using "ESPv2 for OpenAPI" (https://cloud.google.com/endpoints/docs/choose-endpoints-option ) but how do we get there from where we are now, e.g. 1st generation java8, initially based on Mobile Backend Starter (https://github.com/googlearchive/solutions-mobile-backend-starter-java ) from some years ago?
Thanks,
- Gary
There's an indication that GAE standard 2nd generation should be using "ESPv2 for OpenAPI" (
Thanks,
- Gary
em...@gmail.com <em...@gmail.com> #3
Yes, a migration solution for GAE and Android based on the Mobile Backend Starter solution is essentially what is needed.
Description
However, the documentation only shows how to use Java 8 for GAE Standard with Endpoints Frameworks (
There are some notes on this page (
What is needed is:
1. Documentation on how to migrate an existing GAE Standard Java Endpoints Frameworks project off of Endpoints Frameworks and create and deploy your own server. This includes migrating Endpoints Frameworks annotations and method decorations as well.
2. Documentation on how to migrate iOS, Android and Web client libraries that are generated by the Endpoints Frameworks. The ability to easily generate client libraries was a huge selling point of Cloud Endpoints ( for example:
3. Documentation on how to create a new GAE Standard Java 11/17 Cloud Endpoints project without using Endpoints Frameworks is needed. This would be helpful for people who want to start over fresh with a GAE Standard Java Cloud Endpoints solution but do not want to deal with hassle of figuring out which Java web server to use. And also, have the ability to generate client side libraries to consume the api.