OSGeo - User contributions [en]

Java 2018 Code Sprint

2018-09-18T20:49:30Z

Wiki-Dvntucker: /* Participants */

The Java tribe has a real challenge for 2018 - updating our open source projects for the Java roadmap.

== Location ==

Sprint scheduled for Q4 2018, proposed date:

* October 22-26th

We are looking at setting up a distributed sprint with locations in:

* North America - Victoria, Boundless Office, billeting options available for those travelling
* Europe - Sevilla, Spain half.confirmed. Italy or UK have been proposed, recommendations welcome!
* Oceania - recommendations welcome

=== Contacts ===

Jody Garnett

== Sponsors ==

We would like to thank our sponsors!

=== Gold Sponsors ===

TBD

=== Bronze Sponsors ===

TBD

=== In-Kind Support ===

[[File:Boundless_Logo.png|350px|link=http://boundlessgeo.com]] [[File:GeoCat.png|350px|link=https://www.geocat.net]]

== Participants ==

Please add your name and the projects you are planning to sprint and note the likehood of your attendance.

{| style="border: solid grey 1px; width:100%" class="sortable"
|+ Participants
|-
| # || Participant || Country || Organization || Arrival || Departure || Project Work on || Notes || Attendance
|-
| 1 || [[User:Delawen|María Arias de Reyna]] || Spain || GeoCat bv || working remotely || working remotely || GeoNetwork || Notes || Partially working on the codesprint
|-
| 2 || [[User:Jive|Jody Garnett]] || Canada || Boundless || local || local || GeoTools || Able to host guests || Confirmed
|-
| 3 || [[User:Tbarsballe|Torben Barsballe]] || Canada || Boundless || local || local || GeoTools || || Confirmed
|-
| 4 || [[User:ksmith|Kevin Smith]] || Canada || Boundless || local || local || GT/GWC/GS || || Confirmed
|-
| 5 || [[User:dvntucker|Devon Tucker]] || Canada || Boundless || local || local || GT/GS || || Confirmed
|-
|}

== Discussion ==

=== Java has a roadmap? ===

Yes, we had a previous sprint focused on Java 8 compatibility, several features had changed breaking compatibility.

More importantly the Java roadmap has changed to a six-month release cycle:

* six month release cycle is already well underway having started with Java 9 and Java 10.

* Oracle is offering three year LTS releases commercially

* AdoptOpenJDK is setting up LTS releases of OpenJDK .. backed by IBM, Microsoft and others.

* RedHat is focusing on LTS (skipping Java 9 and Java 10) and plans to ship OpenJDK based on Java SE 11

=== Why is updating our open source projects for the Java roadmap a challenge? ===

- Java changed the service provider interface plugin system used by GeoTools, forcing the project to write its own replacement.

- The java runtime has been broken up into modules, not all of which are activated by default. We need to review what sections of the JRE we require and ensure they are turned on.

- Java introduced the module system "jigsaw" providing both a class-path and module-path for loading jars.

- When loaded on the module-path jars are prevented from using the same package. This breaks multi-jar projects like GeoTools library where gt-api defining interfaces, and gt-main providing implementations.

- Jigsaw also locks down aspects of Java reflection, affecting projects like Spring that make heavy use of reflection to "auto wire" GeoServer together. Spring 5 has been released and upgrading to this release will be a key focus.

- With these changes projects like GeoServer need to review of hundreds open source dependencies to determine what other libraries are broken, if an update is available or replacement can be found.

- The java web service framework (responsible for concepts like Servlet and Session) is being removed from Oracle oversight and has been setup as [Jakarta EE Software](https://jakarta.ee).

=== Recommended reading ===

* [https://www.azul.com/what-comes-after-jdk-8/ What Comes After JDK 8?]
* [https://medium.com/criciumadev/its-time-migrating-to-java-11-5eb3868354f9 It's time! Migrating to Java 11] - contains working example of updating spring application
* [http://openjdk.java.net/projects/jigsaw/spec/sotms The State of the Module System] / [https://www.oracle.com/corporate/features/understanding-java-9-modules.html Understanding Java 9 modules]

=== Do you have any experience running sprints? ===

The GeoServer team really benefited from [[Java 2017 Code Sprint|java 2017 code sprint]] and is eager to repeat the success.

== GeoServer Planning ==

Initial planning has started:

* [https://github.com/geoserver/geoserver/wiki/GSIP-171 GSIP 171 Java 18.9 Compatibility] (GeoServer)

Preflight activities:

* dependency audit

Required updates:

* Spring 5 - Older versions of spring are not compatible with Java 11. Upgrading to from Spring 4 to Spring 5 does involve handling some API changes.
* HazelCast - Like Spring, HazelCast involves a lot of reflection.

Module refactor:

* Repackage GeoServer application jars to prevent conflicts at the package level.
* Resulting application can be used on either the CLASSPATH (Java 8) or MODULEPATH (Java 11)

== GeoTools Planning ==

Planning and work is already well underway:

* [https://github.com/geotools/geotools/wiki/Java-9-Compatibility GeoTools Java-9-Compatibility] (GeoTools)

The first completed phase is to allow GeoTools to be used on the classpath:

* [https://github.com/geotools/geotools/wiki/Migrate-Units-to-JSR-363 Migrate Units to JSR-363] (GeoTools)
* [https://github.com/geotools/geotools/wiki/FactoryRegistry-Refactoring-for-Java-9-Compatibility FactoryRegistry Refactoring for Java 9 Compatibility] (GeoTools)

The sprint goal is to refactor the geotools library into modules, allowing the jars to be used on either the classpath (Java 8) or the module path (Java 11).

* [https://github.com/geotools/geotools/wiki/Restructure-GeoTools-into-Jigsaw-modules Restructure GeoTools into Jigsaw modules] (GeoTools)

* Core library refactored into modules

[[File:Gt-modules.png|frameless|GeoTools Java 11 modules ]]

* plugins used to automatic modules to dependencies on the classpath

[[File:Module-path.png|800px|module-path bridge to classpath]]

In the above illustration the gt-svg module is used as an automatic module publishing org.geotools.renderer.style.svg package. It acts as a bridge to the multi-jar project batik still on the classpath, completely masking the fact batik is used used to read and render svg files. The core module gt-renderer publishes select packages for use, while hiding others. It makes use of ServiceLocator to access the IconFactory implemented by gt-svg and never has direct use of the batik implementation.

For this to work the gt-svg jar has been refactored, moving the icon factory the new package org.geotools.style.svg. This was required as the package org.geotools.renderer.style was already published by gt-renderer.

We expect:

* Initial focus is on the core library, refactoring to allow jars to be used on the module path as named modules
* plugins will remain on the classpath, accessed via service locator, any conflicting packages will not be visible to client code

== JTS Topology Suite Activities ==

Results of bonn code sprint:

* [https://github.com/locationtech/jts/pull/274 Add module names for better Java 9/Jigsaw support] (JTS Topology Suite)

JTS jars can be placed on the module-path used as an automatic module, the jars have been supplied am Automatic-Module-Name using a MANIFEST.MF entry.

For an example.application using jts-core as a module add '''module-info''':

module example.application {
requires org.locationtech.jts; // jts-core
}

== GeoNetwork Planning ==

[[https://github.com/geonetwork/core-geonetwork/wiki/OSGeo-Java-codesprint-2018 Strategy for GeoNetwork]]

== How to sponsorship ==

Contributions will be put towards travel costs for sprint participants 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 benefits / honours:

* Your logo at the top of this page
* Mention in project communication (for example the GeoServer 2.15 release announcement)
* The ability to run on a supported java platform
* Our gratitude :)

This event provides the following sponsorship levels:

{| class="wikitable"
|-
| Gold
| style="text-align:right;" | $2500 USD
|-
| Silver
| style="text-align:right;" | $1500 USD
|-
| Bronze
| style="text-align:right;" | $750 USD
|-
| In-Kind || colspan="3" | In-kind support graciously accepted
|}

This is an official OSGeo event, your contribution counts towards being recognized as an [https://www.osgeo.org/about/how-to-become-a-sponsor/ OSGeo Sponsors].

For more information on sponsorship, please contact [[Jody Garnett]], [[User:Aaime|Andrea Aime]].

=== How to Sponsor ===

# Contact OSGeo [[Treasurer]] for details on using PayPal or to request an invoice:
# The OSGeo [[Treasurer]] will contact both you and the event organizers to acknowledge your sponsorship
#* Please have a logo ready for your organization if you wish to be acknowledged publicly
#* Your event sponsorship, at your request, can contribute towards [http://www.osgeo.org/sponsorship being recognized] as an OSGeo Foundation sponsor

=== Sponsorship Outreach ===

We are reaching out to organizations to see if there is interest in sponsorship:

* Prior sponsors: gaia3d, boundless, ian, geodan, how2map, fossgis, atol, geosolutions, astun
* Local sponsors: astun, vivid solutions, transient software

If there is a lot of local sponsorship we expect to drag the developers away from the task at hand and meet the local community (at a social evening or similar).

=== OSGeo Funding Request ===

The following information is requested by OSGeo Board [[Code_Sprint_Guidelines]], we provided an indication that we would be planning a sprint during the 2018 budget process.

* [[Java_2018_Code_Sprint_Budget_:_Budget|Java 2018 Code Sprint Budget]]

It is intended to that OSGeo be recognized as hosting this event, rather than acknowledged as a sponsor.

[[Category:Code Sprints]]
[[Category:Java Tribe Code Sprint]]

Java 2017 Code Sprint

2017-01-18T23:55:50Z

Wiki-Dvntucker: /* Participants */

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.

== Location ==

We will be hosted at the GeoSolutions offices in beautiful Tuscany for a week long sprint.
Available seats are limited to 10 to 15!

Questions:

# Who would be interested in joining as a participating?
# Who would be interested in sponsoring? ;-)
# Do you have any preferred week between say March 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.

{| style="border: solid grey 1px; width:100%" class="sortable"
|+ Participants
|-
| # || Participant || Country || Organization || Arrival || Departure || Project Work on || Notes || Attendance
|-
| 1 || Andrea Aime || Italy || GeoSolutions || || || CITE or REST API switch || Preference for CITE, I'm game for the REST API switch too || Local
|-
| 2 || Ian Turton || UK || Astun || || || CITE, Java 8 upgrade || Planning
|-
| 3 || Andrea Antonello || Italy || HydroloGIS || || || gvSIG and cross-project ideas || I have a strong preference for the end of March || Planning
|-
| 4 || Jody Garnett || Canada || Boundless || || || GeoServer and GeoTools || Enthusiastic about CITE and REST API work || Planning
|-
| 5 || Niels Charlier || Belgium || Scitus Development || || || GeoServer and GeoTools || Keen to do REST API work, MapBox seems interesting too. || Tentatively planning, possibly partially
|-
| 6 || Torben Barsballe || Canada || Boundless || || || REST API or CITE || Preference for REST API, would also be fine with CITE || Planning
|-
| 7 || Mike Pumphrey || USA || Boundless || || || Documentation || I'll help out with whatever you all decide on || Depends on what dates we decide
|-
| 8 || [[User:ksmith|Kevin Smith]] || Canada || Boundless || || || GeoServer, GeoTools, and GeoWebCache || REST update, Language Update prep, library updates, deguavafication are all interesting || Planning
|-
| 9 || [[User:dvntucker|Devon Tucker]] || Canada || Boundless || || || GeoServer, GeoTools || REST update or CITE tests || Tentative/Planning
|}

== Sponsors ==

We have the following sponsorship levels:

{| class="wikitable"
|-
| Gold
| style="text-align:right;" | $1000 USD
| style="text-align:right;" | €950 EUR
|-
| Silver
| style="text-align:right;" | $500 USD
| style="text-align:right;" | €470 EUR
|-
| Bronze
| style="text-align:right;" | $250 USD
| style="text-align:right;" | €235 EUR
|-
| Beer || colspan="3" | 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 honours:

* 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]], [[User:Aaime|Andrea Amie]].

=== How to Sponsor ===

Sponsorship is accepted through PayPal:

# Navigate to the [http://www.osgeo.org/ OSGeo website]
# Click on the "Donate" button in the top right corner
# Donations are handled through PayPal, when making the donation be sure to:
#* Check the currency (USD rates are provided above)
#* Use the "Add special instructions to the seller" field on the confirmation page to mention the event (example "GeoServer code sprint sponsorship")
#* To make alternative arrangements contact OSGeo [[Treasurer]]
# The OSGeo [[Treasurer]] will contact both you and the event organizers to acknowledge your sponsorship
#* Please have a logo ready for your organization if you wish to be acknowledged publicly
#* Your event sponsorship, at your request, can contribute towards [http://www.osgeo.org/sponsorship being recognized] as an OSGeo Foundation sponsor

We can also ask that OSGeo provide an invoice for payment (contact [[Jody Garnett]], [[User:Aaime|Andrea Amie]] to make arrangements).

=== Sponsorship Outreach ===

We are reaching out to organizations to see if there is interest in sponsorship:

* International organizations (OSGeo, GeoSolutions, Boundless);
* Local organizations

If there is a lot of local sponsorship we expect to drag the developers away from the task at hand and meet the local community (at a social evening or similar).

=== OSGeo Funding Request ===

The following information is requested by OSGeo Board [[Code_Sprint_Guidelines]]:

* [[Java_2017_Code_Sprint_Budget_:_Budget|Java 2017 Code Sprint Budget]]

== GeoServer ==

The GeoServer team really benefited from [[GeoServer Code Sprint 2016|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 [http://cite.opengeospatial.org 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 [http://ares.boundlessgeo.com/jenkins/view/testing-cite/ 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 [https://github.com/boundlessgeo/suite/blob/master/geoserver/webapp/src/main/java/com/boundlessgeo/geoserver/api/controllers/ProjController.java PrjController.java] example and complex [https://github.com/boundlessgeo/suite/blob/master/geoserver/webapp/src/main/java/com/boundlessgeo/geoserver/api/controllers/LayerController.java 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 [https://www.mapbox.com/api-documentation/?language=cURL#styles mapbox example] and [https://github.com/boundlessgeo/suite/wiki/Layers-API boundless example].
** Consider auto generating example output from test case (see [https://projects.spring.io/spring-restdocs/ spring-restdocs])

This activity will require quite a bit of people (all hands on deck).

Reference:

* [https://osgeo-org.atlassian.net/issues/?jql=project%20%3D%20GEOS%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20REST Searching for REST]
* [https://osgeo-org.atlassian.net/issues/?jql=project%20%3D%20GEOS%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20REST 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:

* https://www.mapbox.com/mapbox-gl-style-spec/

* https://boundlessgeo.com/2017/01/using-mapbox-style-objects-open-layers/

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.

{| style="border: solid grey 1px; width:100%" class="sortable"
|+ Libraries
|-
| 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 || 4.1 | 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 to 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.

[[Category:Code Sprints]]
[[Category:Java Tribe Code Sprint]]