Tonight I submitted a pull request which contributes an executable WAR based on my Java embeddedable MySQL package named MariaDB4j& Spring Boot to Mifos, the open-source microfinance platform which ends poverty one line of code at a time. (I've actually been working on this, incl. the MariaDB4j foundation, on and off for 2.5 - 3 years, and I'm very happy that this work is finally v1.0 complete now. Its based on previous work I had done in what seems like eons ago, when I contributed the Workspace 2.0 Setup, and an executable WAR plus EXE launcher (without DB then) to the previous incarnation of Mifos (before Mifos X).
The main functional goals achieved and which will be available after the PR merge are:
A. For end-users interested in easily locally trying out Mifos, or perhaps even small production deployments, instead of the current INSTALL which requires Tomcat & MySQL set-up, one can now instead (literally) just do "java -jar mifos.war", and the Mifos back-end/platform (only, not our AngularJS UI, so far) is ready for business! Tomcat is embedded, DB is included - pure magic! ;-) The port etc. used by MariaDB4j can be configured via e.g. -DmariaDB4j.port=1234. The same Mifos package however can alternatively still ALSO be deployed like a traditional classic WAR in a web container like Tomcat with a JNDI datasource, as before!
B. The new ServerWithMariaDB4jApplication class main() with offers something very similar to above, but targets developers: Imagine e.g. a hackathon for Mifos - yesterday that started, like for end-users, with Tomcat & MySQL download & somewhat cumbersome manual set-up steps, now it's git clone; gradlew.bat eclipse, import project & right-click on ServerWithMariaDB4jApplication to Run As > Java Application - literally. And you can set breakpoints and debug without have to remember how to remote attach! ;-) The gradle tomcatRunWAR used by everyone today is still there, but I expect nobody will have any reason to use it anymore.
C. Easy integration tests - just right-click on the new SpringBootServerLoginTest to Run As > JUnit Test - bang, green. Without setting up a database, building a WAR, launching any script outside of your IDE; whatever is required happens automatically when you extend AbstractSpringBootWithMariaDB4jIntegrationTest, with a fresh database, different from the one used by ServerWithMariaDB4jApplication.
D. ServerApplication is for anyone who doesn't quite trust ;) the MariaDB4j magic which spawns a native DB process from Java (and, tries to ensure it, takes it down on each JVM exit), and prefers to keep running a traditional DB externally as before. So ServerApplication, like ServerWithMariaDB4jApplication, fires up an embedded Tomcat via Spring Boot, but doesn't involve MariaDB4j, instead has a configurable DataSource (via -Dmifos.datasource.port=1234 etc.).
One important change affecting all developers and required by the new features described here is that all Flyway migration DB scripts are no longer in mifosng-db/migrations/core_db/ as before, but now in mifosng-provider/src/main/resources/sql/migrations/core_db (on the classpath).
BTW: As a side effect of this work, I've fixed a few related minor bugs in Mifos X, incl. a badly wrong dependency which pulled loads of Maven normally build time only JARs along into the WAR (and screwed up logging), or an issue causing the job scheduler to only work if the WAR is expanded (which it desn't have to be for java -jar mifos.war, as everything can be nicely loaded from the classpath), as well as cleaner / non-hanging WAR shut down by resolving a stuck non-daemon thread issue (thank you Nikhil Khatwani!), as well as raised a bug which got fixed upstream in Spring Boot core itself. More importantly, related required improvements include automatic on-the-fly reconfiguration of the DB port in the tenants table.
PS: A very small technical problem which I trust someone with more Gradle-ese expertise than I have can easily fix is that the executable WAR only works if built by "gradlew build", but not "gradlew war" which the Mifos build uses for some reason (incl. in its "gradlew dist" task that builds the final product ZIP) - any pull requests fixing build.gradle most welcome! ;-)