Difference between revisions of "Java 2018 Code Sprint"

From OSGeo
Jump to: navigation, search
(Java has a roadmap?)
(Added CCRI as an in-kind sponsor.)
 
(104 intermediate revisions by 12 users not shown)
Line 3: Line 3:
 
== Location ==
 
== Location ==
  
We are looking at setting up a distributed sprint with locations in North America, Europe and Oceania.
+
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
 +
** Software Engineer and Computer Science School, University of Sevilla, Spain
 +
** Astun Office in Epsom, UK several point are gathering there
  
 
=== Contacts ===
 
=== Contacts ===
  
TBD
+
Jody Garnett
  
 
== Sponsors ==
 
== Sponsors ==
  
We would like to thank our sponsors - would you like to be the first?
+
We would like to thank our sponsors!
  
=== Gold Sponsors ===
+
=== Silver Sponsors ===
  
TBD
+
[[File:Gaia3d.png|350px|link=http://www.gaia3d.com/]]
  
 
=== Bronze Sponsors ===
 
=== Bronze Sponsors ===
  
TBD
+
[[File:AstunLogo.png|300px |link=http://astuntechnology.com]] [[File:Osgeo-uk.png|300px |liknk=https://uk.osgeo.org/]] [[File:Atol logo.png|300px|link=https://www.atolcd.com]]
  
 
=== In-Kind Support ===
 
=== In-Kind Support ===
  
TBD
+
[[File:Boundless_Logo.png|300px|link=http://boundlessgeo.com]] [[File:GeoCat.png|300px|link=https://www.geocat.net]] [[File:astun.png|300px|link=https://astuntechnology.com/]]    [[File:Geosolutions.png|150px|link=https://www.geo-solutions.it/]]
 +
[[File:Ccri.png|150px|link=https://www.ccri.com/]]
  
 
== Participants ==
 
== Participants ==
Line 34: Line 44:
 
| # || Participant || Country || Organization || Arrival ||  Departure || Project Work on || Notes || Attendance  
 
| # || Participant || Country || Organization || Arrival ||  Departure || Project Work on || Notes || Attendance  
 
|-
 
|-
 +
| 1 ||  [[User:Delawen|María Arias de Reyna]] || Spain || GeoCat bv || local ||  local || GeoNetwork || Notes || Confirmed
 +
|-
 +
| 2 ||  [[User:Jive|Jody Garnett]] || Canada || Boundless || local || local || GeoTools || Able to host guests || Confirmed
 +
|-
 +
| 3 ||  [[User:Tbarsballe|Torben Barsballe]] || Canada || Boundless || local || local || GT/GS ||  || 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
 +
|-
 +
| 6 ||  [[User:moovida|Antonello Andrea]] || Italy || HydroloGIS || TBD || TBD || GT/JTS, Hortonmachine ||  || Confirmed
 +
|-
 +
| 7 || [[User:ianturton|Ian Turton]] || UK || Astun || local || local || GT/GS || Epsom || 
 +
|-
 +
| 8 || [[User:Aaime|Andrea Aime]] || Italy || GeoSolutions || TBD || TBD || GT/GWC/GS/jai-ext/imageio-ext/jaitools || Home || Confirmed
 +
|-
 +
| 9 || [[User:jhughes|Jim Hughes]] || US || CCRi || TBD || TBD || JTS/GT/GS/GeoMesa || || Confirmed
 +
|-
 +
| 10 || [[User:Surveyor|Landon Blake]] || US || BKF Engineers || Working Remotely || Working Remotely || JTS/Proj4J || || Confirmed
 +
|-
 +
| 11 || David Vick || US || Boundless || STL || remote || GT/GS || || Confirmed
 +
|-
 +
| 12 || Wes Richardet  || US || Boundless || STL || remote || GT/GS || || Confirmed
 
|}
 
|}
  
== Questions ==
+
== Discussion ==
  
 
=== Java has a roadmap? ===  
 
=== Java has a roadmap? ===  
Line 44: Line 77:
 
More importantly the Java roadmap has changed to a six-month release cycle:
 
More importantly the Java roadmap has changed to a six-month release cycle:
  
- Oracle is offering three year LTS releases .. to paying customers
+
* six month release cycle is already well underway having started with Java 9 and Java 10.
- AdoptOpenJDK is setting up LTS releases of OpenJDK .. backed by IBM, Microsoft and others.
+
- RedHat is skipping Java 9 and Java 10 and plans to ship OpenJDK based on Java SE 11
+
  
This 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? ===  
 
=== Why is updating our open source projects for the Java roadmap a challenge? ===  
  
- Java 9 changed the service provider interface plugin system used by GeoTools, forcing the project to write its own replacement.
+
- Java changed the service provider interface plugin system used by GeoTools, forcing the project to write its own replacement.
  
- Java 9 introduced the module system "jigsaw" (introduced for Java 9) prevents two jars from using the same package. This breaks the GeoTools library which as gt-api defining interfaces, and gt-main providing implementations. Projects like GeoServer need to review of over hundred open source dependencies to determine what other libraries are broken, and if an update or replacement can be found.
+
- 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.
 
- 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.
  
- 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.
+
- 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 ===
  
- 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).  
+
* [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]
 +
* [https://github.com/google/guava/pull/2846 Add an Automatic-Module-Name manifest entry] - shows guava project deciding how to name their modules
 +
* [https://www.youtube.com/watch?v=MGX-JfMl9-Y Modules in One Lesson] - Good introduction to modules.
  
 
=== Do you have any experience running sprints? ===  
 
=== Do you have any experience running sprints? ===  
Line 66: Line 113:
 
The GeoServer team really benefited from [[Java 2017 Code Sprint|java 2017 code sprint]] and is eager to repeat the success.
 
The GeoServer team really benefited from [[Java 2017 Code Sprint|java 2017 code sprint]] and is eager to repeat the success.
  
=== What is the plan? ===  
+
== GeoServer Planning ==
  
With such a large task plans are well underway:
+
Initial planning has started:
  
* [[https://github.com/geoserver/geoserver/wiki/GSIP-171|GSIP 171 Java 18.9 Compatibility]] (GeoServer)
+
* [https://github.com/geoserver/geoserver/wiki/GSIP-171 GSIP 171 Java 18.9 Compatibility] (GeoServer)
* [[https://github.com/geotools/geotools/wiki/Java-9-Compatibility|GeoTools Java-9-Compatibility]] (GeoTools)
+
  
With some steps already completed:
+
Preflight activities:
  
* [[https://github.com/geotools/geotools/wiki/Migrate-Units-to-JSR-363|Migrate Units to JSR-363]] (GeoTools)
+
* dependency audit
* [[https://github.com/geotools/geotools/wiki/FactoryRegistry-Refactoring-for-Java-9-Compatibility|FactoryRegistry Refactoring for Java 9 Compatibility]]
+
 
* [[https://github.com/locationtech/jts/pull/274|Add module names for better Java 9/Jigsaw support] (JTS Topology Suite)
+
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]]
 +
 
 +
== Sprint Coordination ==
 +
 
 +
=== Communication ===
 +
 
 +
While many of us are meeting in person, we still need to communicate across teams and timezones:
 +
 
 +
* [https://docs.google.com/spreadsheets/d/1oE6mU4jp-ZL5PebgXf-fuhtf7MY5dzSwPqpMtrzdZ94/edit#gid=1150591858 Java 2018 Code Sprint Activities] - group spreadsheet
 +
* https://gitter.im/OSGeo/Sprint - casual communication, ask for help if you are stuck for more than ten mins
 +
* https://jitsi.org - hangout and share screen
 +
 
 +
=== Coordination ===
 +
 
 +
Care is required to commit everything, and hand over work from one timezone to the next.
 +
 
 +
* Use of the [https://docs.google.com/spreadsheets/d/1oE6mU4jp-ZL5PebgXf-fuhtf7MY5dzSwPqpMtrzdZ94/edit#gid=1150591858 Java 2018 Code Sprint Activities] spreadsheet is key preventing two people working on the same problem.
 +
* Ask on gitter and put your name next to an activity
 +
* If you need to step out, or are done for the day, be sure to commit progress and let others continue!
 +
 
 +
=== Preflight checklist ===
 +
 
 +
To help get ready we have assembled a preflight checklist:
 +
 
 +
# JDK 11: Please install OpenJDK11
 +
#* https://jdk.java.net/11
 +
# Fork and clone out each project and build locally (Java 8 / master branch)
 +
#* jaitools
 +
#* jai-ext
 +
#* imageio-ext
 +
#* geotools
 +
#* geowebcache
 +
#* geoserver
 +
# Read the proposals:
 +
#* [[Java_2018_Code_Sprint]]
 +
#* [https://github.com/geoserver/geoserver/wiki/GSIP-171 GSIP-171 Java 18.9 Compatibility]
 +
#* [https://github.com/geotools/geotools/wiki/Restructure-GeoTools-into-Jigsaw-modules Restructure GeoTools into Jigsaw modules]
 +
# Required reading:
 +
#* This wiki page, especially '''Sprint Activities''', below.
 +
#* [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]
 +
# Recommended reading:
 +
#* [https://www.amazon.com/Core-Java-SE-Impatient-2nd/dp/0134694724 Core Java SE 9 for the Impatient] (Chapter 15. The Java Platform Module System)
 +
#* [https://www.oracle.com/corporate/features/understanding-java-9-modules.html Understanding Java 9 modules]
 +
#* [http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html jpms automatic modules]
 +
#* [jpms module naming http://blog.joda.org/2017/04/java-se-9-jpms-module-naming.html]
 +
# Background:
 +
#* [https://www.youtube.com/watch?v=MGX-JfMl9-Y Modules in One Lesson] - Good introduction to modules.
 +
#* [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
 +
#* [https://www.azul.com/what-comes-after-jdk-8/ What Comes After JDK 8?]
 +
#* [https://github.com/google/guava/pull/2846 Add an Automatic-Module-Name manifest entry] - shows guava project deciding how to name their modules
 +
 
 +
=== Sprint Activities ===
 +
 
 +
The sprint is broken up into several stages, goal is to have something deliverable at the end of each stage. Care has been taken to identify activities that can be worked on in parallel.
 +
 
 +
==== Stage 1 Build and run in JDK 11 ====
 +
 
 +
''Done when being able to start and run GeoServer on JDK11 with release extensions loaded in''
 +
 
 +
Everything in our stack builds and run without any flag added, off the classpath (it's ok to have warnings). This will allow us to get JDK 11 builds going.
 +
 
 +
* '''Compile:''' Andrea has made considerable progress here, to mirror you need to check out and build locally all the dependencies
 +
* '''Tests:''' passing tests can be worked on in parallel, as long as pervious stages were able to compile without tests. This work may require updating some dependencies
 +
* '''Build:''' package release artifacts such as installers and javadocs
 +
 
 +
{| class="wikitable"
 +
| Project
 +
| Compile
 +
| Test
 +
| Build
 +
|-
 +
| jaitools
 +
| -
 +
| -
 +
| -
 +
|-
 +
| jai-ext
 +
| x
 +
| -
 +
| -
 +
|-
 +
| imageio-ext
 +
| x
 +
| -
 +
| -
 +
|-
 +
| geotools
 +
| x
 +
| -
 +
| -
 +
|-
 +
| geowebcache
 +
| x
 +
| -
 +
| -
 +
|-
 +
| geoserver
 +
| x
 +
| -
 +
| -
 +
|}
 +
 
 +
==== Stage 2 Reduce warnings from Dependency Analysis Tools ====
 +
 
 +
''Done when code we have control over has addressed dependency analysis warnings (except split packages)''
 +
 
 +
This cannot be automated, and is why we have so many people in the sprint!
 +
 
 +
* '''Resolve Warning:''' Address warnings from our codebase, many warnings provide clear guidance (will need to save split packages to the next stage.)
 +
* '''Upgrade Dependencies:''' Upgrade dependencies to resolve warnings (should still compatible with Java 8 via mule-release jar or similar.)
 +
 
 +
Coordination using our spreadsheet will be key as dependency upgrades are transitive to downstream projects.
 +
 
 +
==== Stage 3 Module repackage ====
 +
 
 +
''Done when split-module warnings are resolved, and geotools demo applications can run on the module path.''
 +
 
 +
Add automatic module descriptors, eliminate split packages in library projects, add module-info.java only if needed.
 +
 
 +
* '''Repackage:''' Repackage each codebase as required to address-split modules
 +
* '''Module App:''' Make sure we can run a true module app depending on the automatic modules
 +
* '''Imports:''' Adjust imports and the like as needed in all projects, try to collect migration scripts to help others do the same.
 +
 
 +
Discussion:
 +
 
 +
* Choice between using eclipse api baseline to generate migration script, or writing sed scripts by hand.
 +
 
 +
==== Stage 4 org.opengis repackage ====
 +
 
 +
''Done when references to org.opengis package are removed''
 +
 
 +
Swich gt-api away from using org.opengis package, upgrade everything else to follow
 +
* '''Repackage:''' Repackage org.opengis interfaces into appropriate org.geotools package
 +
* '''EMF Model:''' Update emf models and regenerate
 +
 
 +
Discussion:
 +
 
 +
* Updating EMF models requires figuring out which version of eclipse was used to generate
 +
 
 +
=== Postsprint Activities ===
 +
 
 +
* Blog capturing sprint results and thanking sponsors
 +
* We would like to issue a milestone release giving downstream projects a chance to migrate ahead of January release candidate.
  
 
== How to sponsorship ==
 
== How to sponsorship ==
  
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.
+
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:
 
Sponsors will receive the following benefits / honours:
  
 
* Your logo at the top of this page
 
* Your logo at the top of this page
* Mention in all of our public communication, including GeoServer 2.15 release announcement
+
* Mention in project communication (for example the GeoServer 2.15 release announcement)
 +
* The ability to run on a supported java platform
 
* Our gratitude :)
 
* Our gratitude :)
  
Line 94: Line 341:
 
|-
 
|-
 
| Gold
 
| Gold
| style="text-align:right;" | $5000 USD
+
| style="text-align:right;" | $2500 USD
 
|-
 
|-
 
| Silver
 
| Silver
| style="text-align:right;" | $1000 USD
+
| style="text-align:right;" | $1500 USD
 
|-
 
|-
 
| Bronze
 
| Bronze
| style="text-align:right;" | $500 USD
+
| style="text-align:right;" | $750 USD
 
|-
 
|-
 
| In-Kind || colspan="3" | In-kind support graciously accepted
 
| In-Kind || colspan="3" | In-kind support graciously accepted
Line 111: Line 358:
 
=== How to Sponsor ===
 
=== How to Sponsor ===
  
# Contact OSGeo [[Treasurer]] for details on using PayPal or to request an invoice:
+
# Sponsorship is accepted through the Open Source Geospatial Foundation
# The OSGeo [[Treasurer]] will contact both you and the event organizers to acknowledge your sponsorship
+
#* Use [https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=CP5NFWKN2VRFG OSGeo PayPal] link, funds are in USD marked towards "OSGeo Foundation java code sprint".
 +
#* To make alternative arrangements or request an invoice contact OSGeo Treasurer: treasurer@osgeo.org
 +
# Once sponsorship is received the OSGeo [[Treasurer]] will contact you and the event organizers to acknowledge your sponsorship
 
#* Please have a logo ready for your organization if you wish to be acknowledged publicly  
 
#* 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
 
#* Your event sponsorship, at your request, can contribute towards [http://www.osgeo.org/sponsorship being recognized] as an OSGeo Foundation sponsor
Line 120: Line 369:
 
We are reaching out to organizations to see if there is interest in sponsorship:
 
We are reaching out to organizations to see if there is interest in sponsorship:
  
* International organizations (OSGeo, GeoSolutions, Boundless);
+
* Prior sponsors: gaia3d, boundless, ian, geodan, how2map, fossgis, atol, geosolutions, astun
* Local organizations
+
* 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).
 
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).
Line 127: Line 376:
 
=== OSGeo Funding Request ===
 
=== 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.
+
The following information is requested by OSGeo Board [[Code_Sprint_Guidelines]], the projects involved indicated that we would be planning a sprint during the 2018 budget process.
 +
 
 +
* [https://docs.google.com/spreadsheets/d/1bSuf32MjgP7NKZcqvV7IilpxakKdocJ4CPUEF8jq5Z4/edit#gid=990228872 Java 2018 Code Sprint Budget]
  
* [[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:Code Sprints]]
 
[[Category:Java Tribe Code Sprint]]
 
[[Category:Java Tribe Code Sprint]]

Latest revision as of 08:27, 26 October 2018

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
    • Software Engineer and Computer Science School, University of Sevilla, Spain
    • Astun Office in Epsom, UK several point are gathering there

Contacts

Jody Garnett

Sponsors

We would like to thank our sponsors!

Silver Sponsors

Gaia3d.png

Bronze Sponsors

AstunLogo.png liknk=https://uk.osgeo.org/ Atol logo.png

In-Kind Support

Boundless Logo.png GeoCat.png Astun.png    Geosolutions.png Ccri.png

Participants

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

Participants
# Participant Country Organization Arrival Departure Project Work on Notes Attendance
1 María Arias de Reyna Spain GeoCat bv local local GeoNetwork Notes Confirmed
2 Jody Garnett Canada Boundless local local GeoTools Able to host guests Confirmed
3 Torben Barsballe Canada Boundless local local GT/GS Confirmed
4 Kevin Smith Canada Boundless local local GT/GWC/GS Confirmed
5 Devon Tucker Canada Boundless local local GT/GS Confirmed
6 Antonello Andrea Italy HydroloGIS TBD TBD GT/JTS, Hortonmachine Confirmed
7 Ian Turton UK Astun local local GT/GS Epsom
8 Andrea Aime Italy GeoSolutions TBD TBD GT/GWC/GS/jai-ext/imageio-ext/jaitools Home Confirmed
9 Jim Hughes US CCRi TBD TBD JTS/GT/GS/GeoMesa Confirmed
10 Landon Blake US BKF Engineers Working Remotely Working Remotely JTS/Proj4J Confirmed
11 David Vick US Boundless STL remote GT/GS Confirmed
12 Wes Richardet US Boundless STL remote 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

Do you have any experience running sprints?

The GeoServer team really benefited from java 2017 code sprint and is eager to repeat the success.

GeoServer Planning

Initial planning has started:

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:

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

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).

  • Core library refactored into modules

GeoTools Java 11 modules

  • plugins used to automatic modules to dependencies on the classpath

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:

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

[Strategy for GeoNetwork]

Sprint Coordination

Communication

While many of us are meeting in person, we still need to communicate across teams and timezones:

Coordination

Care is required to commit everything, and hand over work from one timezone to the next.

  • Use of the Java 2018 Code Sprint Activities spreadsheet is key preventing two people working on the same problem.
  • Ask on gitter and put your name next to an activity
  • If you need to step out, or are done for the day, be sure to commit progress and let others continue!

Preflight checklist

To help get ready we have assembled a preflight checklist:

  1. JDK 11: Please install OpenJDK11
  2. Fork and clone out each project and build locally (Java 8 / master branch)
    • jaitools
    • jai-ext
    • imageio-ext
    • geotools
    • geowebcache
    • geoserver
  3. Read the proposals:
  4. Required reading:
  5. Recommended reading:
  6. Background:

Sprint Activities

The sprint is broken up into several stages, goal is to have something deliverable at the end of each stage. Care has been taken to identify activities that can be worked on in parallel.

Stage 1 Build and run in JDK 11

Done when being able to start and run GeoServer on JDK11 with release extensions loaded in

Everything in our stack builds and run without any flag added, off the classpath (it's ok to have warnings). This will allow us to get JDK 11 builds going.

  • Compile: Andrea has made considerable progress here, to mirror you need to check out and build locally all the dependencies
  • Tests: passing tests can be worked on in parallel, as long as pervious stages were able to compile without tests. This work may require updating some dependencies
  • Build: package release artifacts such as installers and javadocs
Project Compile Test Build
jaitools - - -
jai-ext x - -
imageio-ext x - -
geotools x - -
geowebcache x - -
geoserver x - -

Stage 2 Reduce warnings from Dependency Analysis Tools

Done when code we have control over has addressed dependency analysis warnings (except split packages)

This cannot be automated, and is why we have so many people in the sprint!

  • Resolve Warning: Address warnings from our codebase, many warnings provide clear guidance (will need to save split packages to the next stage.)
  • Upgrade Dependencies: Upgrade dependencies to resolve warnings (should still compatible with Java 8 via mule-release jar or similar.)

Coordination using our spreadsheet will be key as dependency upgrades are transitive to downstream projects.

Stage 3 Module repackage

Done when split-module warnings are resolved, and geotools demo applications can run on the module path.

Add automatic module descriptors, eliminate split packages in library projects, add module-info.java only if needed.

  • Repackage: Repackage each codebase as required to address-split modules
  • Module App: Make sure we can run a true module app depending on the automatic modules
  • Imports: Adjust imports and the like as needed in all projects, try to collect migration scripts to help others do the same.

Discussion:

  • Choice between using eclipse api baseline to generate migration script, or writing sed scripts by hand.

Stage 4 org.opengis repackage

Done when references to org.opengis package are removed

Swich gt-api away from using org.opengis package, upgrade everything else to follow

  • Repackage: Repackage org.opengis interfaces into appropriate org.geotools package
  • EMF Model: Update emf models and regenerate

Discussion:

  • Updating EMF models requires figuring out which version of eclipse was used to generate

Postsprint Activities

  • Blog capturing sprint results and thanking sponsors
  • We would like to issue a milestone release giving downstream projects a chance to migrate ahead of January release candidate.

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:

Gold $2500 USD
Silver $1500 USD
Bronze $750 USD
In-Kind In-kind support graciously accepted

This is an official OSGeo event, your contribution counts towards being recognized as an OSGeo Sponsors.

For more information on sponsorship, please contact Jody Garnett, Andrea Aime.

How to Sponsor

  1. Sponsorship is accepted through the Open Source Geospatial Foundation
    • Use OSGeo PayPal link, funds are in USD marked towards "OSGeo Foundation java code sprint".
    • To make alternative arrangements or request an invoice contact OSGeo Treasurer: treasurer@osgeo.org
  2. Once sponsorship is received the OSGeo Treasurer will contact 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 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, the projects involved indicated that we would be planning a sprint during the 2018 budget process.

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