Java 2017 Code Sprint
The current plan is for the Java tribe to meet in Italy at the start of March. This page will allow us to plan the event.
We will be hosted at the GeoSolutions offices in beautiful Tuscany for a week long sprint.
Questions:
- Who would be interested in joining as a participating?
- Who would be interested in sponsoring? ;-)
- Do you have any preferred week between say Feb 13 and end of March?
Participants
Please add your name and the projects you are planning to sprint and note the likehood of your attendance.
| # | Participant | Country | Organization | Arrival | Departure | Project Work on | Attendance / Notes | |
| 1 | Andrea Aime | Italy | GeoSolutions | CITE or REST API switch | Preference for CITE, I'm game for the REST API switch too | |||
| 2 | Ian Turton | UK | Astun | CITE, Java 8 upgrade | ||||
| 3 | Andrea Antonello | Italy | HydroloGIS | gvSIG and cross-project ideas | I have a strong preference for the end of March | |||
| 4 | Jody Garnett | Canada | Boundless | GeoServer and GeoTools | Enthusiastic about CITE and REST API work |
Sponsors
We have the following sponsorship levels:
| Gold | $1000 USD | €950 EUR | |
| Silver | $500 USD | €470 EUR | |
| Bronze | $180 USD | €235 EUR | |
| Beer | In-kind contributions are graciously accepted | ||
Contributions will be put towards travel costs for overseas sprinters who would be otherwise unable to attend. Any surplus at the end of the event will be turned over to OSGeo or used for a future code sprint. We have set-up the sprint to minimize travel and accommodation costs.
Sponsors will receive the following honors:
- Your logo at the top of this page
- Mention in all of our public communication, including GeoServer 2.9 release announcement
- Our gratitude :)
For more information on sponsorship, please contact Jody Garnett, Andrea Amie or the OSGeo Treasurer.
GeoServer
The GeoServer team really benefited from geoserver code sprint 2016 and is eager to repeat the success.
GeoServer Plans (choose ONE of the following)
We are still at the planning stage so please let us know if a particular topic interests you or would be a deal breaker. The sprint does not have to be a single topic, if we can swarm a large beast good, but if someone wants to join and work on a side topic to leverage the presence of others, that’s good too.
CITE
The OGC Compliance Program provides the CITE tool for testing standards compliance. Our build process makes heavy use of this tool ... ensuring that each and every release of GeoServer correctly implements WMS, WFS, and WCS.
There are three problems with this:
- We last updated our CITE build tool 2012 (so our testing is quite out of date).
- Our geoserver.org website can only say we are a "compliant implementation", rather than a "certified implementation" of the WCS, WMS and WFS standards.
- New services such as WPS and CSW are not "blackbox" tested.
The OGC provide the CITE Team Engine both as a web service and as an open source project that can be used to check a single instance of GeoServer. This is a little awkward as we would like to integrate these tests into our build server; as such our build server stands up a geoserver instance, performance the tests, and publishes the results here. These tests also require a database - and modify that database over the course of the tests (so our build server needs a PostGIS running).
Armed with a positive test result we can ask OSGeo to pay for OGC certification, allowing us to update our website. As an alternative to paying money the OGC allows open source projects to be listed as a "reference implementation" (providing an instance of the server is available online for potential clients to test against).
Rough planning:
- Upgrade the test harness
- Make sure the tests are still passing (probably they won’t),
- Add new test that we are missing
- WFS 2.0,
- WCS 2.0
- CSW
- WMTS 1.0
- WPS 1.0,
- maybe GML and KML and GeoPackage
- OGC Certification
- Submit required paperwork, and test results, update website
- Reference Implementation
- Maybe stand up a reference server for OGC to use (if OSGeo or OGC provide hardware) with one test per workspace/virtual service?
REST API
The REST API for GeoServer is popular, but not well maintained, collecting a large number of outstanding bugs. Many of these complain about functionality and lack of documentation. The large number of bugs (API called correctly but produced an error) may be producing more requests for documentation (developer assumed they called it incorrectly, and asks for improved documentation with an example that works).
Internally the REST API is written using an early java library called "restlet" (http://restlet.com/). There is a desire to migrate to spring rest api which is annotation driven and better supported. The risk in performing a migration to Spring MVC is introducing more bugs than are fixed. This is somewhat offset by having a larger pool of developers familiar with the codebase and the technologies used.
/**
* API endpoint to get details on a specific layer
* @param wsName The workspace name
* @param name The layer name
* @param req The HTTP request
* @return The layer, encoded as a JSON object
*/
@RequestMapping(value="/{wsName}/{name:.+}", method = RequestMethod.GET)
public @ResponseBody JSONObj get(@PathVariable String wsName, @PathVariable String name, HttpServletRequest req) {
Rough plan:
- Create a rest-ng module (alongside existing rest, restconfig, importer-rest, ....)
- Module based on Spring MVC - see simple PrjController.java example and complex LayerController.java example.
- Set up converters/encoders for resources
- Migrate restconfig functionality
- Migrate importer-rest functionality
- resource-rest-api
- rest-upload
- Audit functionality against GUI
- shortlist missing functionality for proposal and implementation (examples recalculate feature type columns, rest layer bounds from SRS boudns, ...)
- Test cases should remain unchanged
- Documentation
- Set up documentation team operating concurrently, capturing each resource as it is completed
- Go for a resource description, json and xml example, example of each kind of request (GET, PUT, POST, DELETE) as appropriate. See mapbox example and boundless example.
- Consider auto generating example output from test case (see spring-restdocs)
This activity will require quite a bit of people (all hands on deck).
Reference:
- Searching for REST
- Searching for Module (not always properly assigned)
Mapbox Style
The GeoServer application can be extended to work with multiple styling languages (SLD, CSS, YSLD). Mapbox has recently defined an open standard for drawing vector tiles that has been picked up by not only their own software but by the OpenLayers team. Initial investigation into this standard shows that it is a "whole" map standard similar to "sld" describing both the layers that make up the map, and the symbology used to represent them visually.
While some features (3d extrusions, camera and lighting angle) are not suitable for use by GeoServer the rest of it looks quite fun.
References:
Rough planning:
- Focus on styling a single layer using a mapbox style
- Requires a parser for mapbox style capable of producing the internal geotools style objects; package as a geotools community module.
- Setup geoserver extension and integration for new style format
- Whole map styling (optional)
- LayerGroup defines both an order of layers, and the style associated with each layer - this information can be defined from a single mapbox style
- (Optional) Consider offering SLD the same ability to define a LayerGroup
Library upgrades
Last year's sprint was devoted to updating a key library and required all hands on deck to help make the transition a smooth one. Ideally we would like to stay on top of library upgrades; however often a change to one has a cascade effect as we need to update (and test) each library in turn.
| Library | Version | Latest | Description | |
| Wicket | 7.1.0 | 7.6.0 | user interface (note 8.x milestones being released presently) | |
| hsql | 2.3.0 | 2.3.4 | java database | |
| h2 | 1.1.119 | 1.3.176 | java database (1.4.x beta currently available) | |
| commons-dbcp | 1.4 | 2.2 | database connection pool | |
| commons-beanutils | 1.9.2 | 1.9.3 | java bean utility library | |
| commons-collections | 3.2.2 | java collection classes | ||
| guava | 17.0 | 21.0 | java collection classes and more | |
| log4j | 1.2.12 | 2.7 | supports java 8 lambda, consider migrating to yaml/json config? | |
| (and much more) |
Note:
- We may wish to migrate from guava from java 8 and commons collections; as guava often produces conflicts for downstream projects
GeoTools
GeoTools Plans
The GeoTools codebase has a number of smaller of ideas that may of be of interest to volunteers:
- JDK 9 + maybe JDK 8 updates in the code base (like stream ready support for feature collection, where we can use lambda for profit)
- JDK 9 replacement for plugin system (service registry) is required
The above ideas may also be suitable to anyone attending remotely who like the focus and support of a dedicated code sprint block on the calendar.