For switching to standalone jar we would first need to publish it (#4525). Once we make it available for download somewhere we can then guide users to download it from there
> I also like the standalone JAR. Should we consider adding to that the API Management features made available through OW GW, or for that we should keep the docker-compose route If we would like to simplify the Api GW usage specially with standalone case then we can possibly try adding some support for it within standalone flow itself 1. Package the route management action zips in jar 2. Upon startup (say with -g flag) it would install the routes 3. It would then also spin up required containers like api gw, redis, minio? So end user may just need to run with `-g` flag to get the gateway functionality working. Chetan Mehrotra On Sat, Jul 13, 2019 at 12:40 AM Rodric Rabbah <rod...@gmail.com> wrote: > > > I also like the standalone JAR. Should we consider adding to that the API > Management features made available through OW GW, or for that we should > keep the docker-compose route ? > > I did get the API gateway to run (in the container) with standalone > openwhisk. I ran the ansible playbook (wskdev apigw) to get it up and > going. It doesn't work with sls (serverless framework because of the DNS > resolution issue I've posted about in the past) but will work with wsk. > > -r
