| [geogig-dev] geogig migration from restlet to spring mvc |
Checking in after GeoSever REST API sprint; we would like a chance to catch up (hangout?) mid week to sort out plans for migrating the geogig plugin from restlet to spring mvc.
The geogig plugin uses a dependency on the geogig web/api which is written in restlet. It reuses elements of this restlet implementation directly:
There are two approaches that make sense with different consequences for the GeoGig roadmap
Alternative: Migrate web/api and web/app plugins to Spring MVC
First approach is to do what is being done for geoserver master, port the api to spring-mvc later this week (and then reuse these elements in the geoserver geogig plugin).
This work can be done on geogig dev and then backported to master in six months time when GeoServer 2.12 is released. The downside is that at that point the single goegig build will not work on GeoServer 2.9, 2.10, 2.11, 2.12 :)
Alternative: Duplicate web/api plugin
The second approach is to do something different for geogig codebase.
Leave the web/app and web/api as is, but do not depend on these geoserver master.
Instead make a web/mvc plugin that is based on spring mvc, duplicating the web/api and test cases. The geoserver master code base would change from depending on web/api to depending on web/mvc.
This approach has the advantage of allowing a single deploy of geogig to work for GeoServer 2.9,2.10,2.11,2.12 in six months time.
The downside is geoserver master would like to depend on dev? (unless we backport web/api to master).
Q: What approach would you like to take out of the two above?
Q: Are the spring MVC dependencies okay with locationtech ip review? (License is Apache Version 2.0. so I hope it is already approved)
--
Jody Garnett