ninjaframework/ninja — pull request #229 by gitblit (2014-09-15 19:22:34+00:00)
Title: RFC: One way to modularize Ninja

This PR is an exercise in determining how `ninja-core` could be broken into a few more pieces. This lowers the footprint of ninja-core and it's deps by at least 15MB primarily by eliminating hard dependencies on caching and persistence technologies. It also allows devs to more discretely pick their technologies.

The first two commits (engine logging) have also been submitted separately as #228. Part of their motivation is for this PR, but they have value outside the scope of this PR too.

The third commit sets-up the JPA/persist module since the current design is to pass `NinjaProperties` to the `JpaModule` constructor.

The remainder of the commits are mostly the grunt work required to make ninja-core un-opinionated and to ensure that Ninja passes all unit tests between extractions. Being un-opinionated means that things like `ninja-freemarker` and `ninja-jackson` **must** be specified as dependencies in the application pom because out-of-the-box ninja-core is incapable of generating content.

I'm not saying this breakdown is the best one, but it does highlight some tricky spots like `JpaModule`, `Migrations`, and `CacheProvider`.

It also begs the question: what is a Ninja Module? The current answer (Guice Module + Providers) isn't very formal. In a different PR I advocated an auto-register annotation for modules. Maybe something like that could be upstreamed or perhaps a Interface definition? Not sure. In any event, I'm interested to hear your feedback.