Currently the way revel cmd operates is that it is basically a bunch of function calls that dynamically build a couple of go files and launches them. The cmd program continues to run in the background (when in developer mode) to watch for source file changes and if detected it will trigger a rebuild and reload. This is all done with code that is loosely coupled together, and does not support unit testing.

I think the best approach at this point is to start with a fresh project on this that does the same thing but is developed in a way that supports the following

• Unit Testing
• A pluggable architecture for new types of revel applications
• Extend existing applications by adding new controllers and components

Then at some point in the future we will switch from revel/cmd to revel/run

Add ability to generate a skeleton framework that would be a pure restful interface, preferably using RAML (http://raml.org/) - Restful API Modeling Language. or maybe pluggable to use multiple

References
https://github.com/kishorevaishnav/revelgen
https://github.com/xeipuuv/gojsonschema

Aggregate from issues
revel/revel#968
revel/revel#120
revel/cmd#81
revel/cmd#64
revel/revel#845

Enhancements

• Symlink directory resolver, go through the GOPATH directory structure to try and detect a temp file creation, the temp file will be created initially.
• Swagger / Raml support. The general support for these have been to generate routes based on the configuration data. Then stub out a controller class with the method call.
• Unit testing.
• Configuration file detection changes
• Source file detection changes
• Template file detection changes
• Custom build arguments #10
• Add relative path support to all revel commands like revel run
• Docker file generation
  Here is a simple template for a minimal Dockerfile, using a small Debian for a new small container:

FROM debian:stable
COPY ./{{.BinName}} /revel/{{.BinName}}
COPY ./run.sh /revel/run.sh
COPY ./src  /revel/src

CMD ["/bin/sh", "/revel/run.sh"]

EXPOSE 9000