Proposal: Seperate, spring enable mapfish print. 2.1 Milestone?

Mapfish print is an application that has servlet and command line wrappers.

Proposal 1:

I propose splitting the application into mapfish-print-core, and then sub-projects, mapfish-print-web, and mapfish-print-cli which inherit/wrap the core capabilities.

This will allow better organization and navigation of the code and project.

Proposal 2:

I propose fully integrating the application into the spring framework. This would provide many benefits. First, the codebase is already using many of the spring conventions, just not getting the advantage of them being available from a framework (auto-wiring of beans, property injection, etc).

Second, by spring enabling the code, a world of plugins and extensions become available (none more important than security modules available out of the box).

Spring-web info can be found: http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/mvc.html Spring-cli info can be found at: http://docs.spring.io/spring-shell/docs/current/reference/html/dev-shell.html

Proposal 3:

Further segment the mapfish-print-core codebase to allow different implementation of certain functions (some people may want to use geotools geojson support instead of mapfish. The same for json parsers, etc). By abstracting these implementation decisions out of the core codebase, we would make the library much more applicable to downstream projects.

Currently the code is very mapfish centric, while the majority of the application is more aligned with OpenLayers and client side mapping than server side functionality anyway. This would also allow for more upstream libraries to be integrated and the possibility for less code to write (and maintain).