The purpose here is to shorten and simplify the code-build-run-test-debug cycle through automation.
A programmer will create a project in any of the recommended build tools: e.g.
- Maven
- Gradle
- NPM
The project is executed as hot-deploy using a technique appropriate for the build tool.
e.g. for Maven, the execution may invoke: mvn vertx:hot.
On execution, the primary verticle is deployed; this in turn may:
- Deploy other verticles
- Access third-party libraries using the build tool binding (TODO: provide a reproducer for an issue with this)
- Use the Vert.x APIs
- Implement custom logic
Any change to files that affect the logical behaviour of the program will cause recompile and redeploy. Files that may cause this:
- Source code
- Configuration
- Templates (that statically compiled)
- and others
Presumably, the convention of the build tool can be followed. So for example, in Maven, ${project.build.sourceDirectory} can be used for the source of the watch.
The recompile step will invoke the respective build tool's goal.
Logically, the vert.x verticles will be undeployed and the newly compiled primary verticle will be re-deployed. No effort will be made to maintain state.
In the case of build tools that closely aligned to the JVM (Maven, Gradle) the hot-deploy phase can be run in debug mode enabling the programmer to break-point and step through the programme whilst the above cycle of steps carry on.