[Geotools-devel] PSC Meeting - 2031-01-17

[Jody G. <jod...@gm...>]

GeoTools / GeoServer PMC meeting - 2023-01-17Attending

   -

   Torben Barsballe
   -

   Andrea Aime
   -

   Kevin Smith
   -

   Jody Garnett


Actions from prior meetings:

   -

   N/A

Agenda

   1.

   GeoServer release schedule
   2.

   Spring upgrade
   3.

   OSGeo Budget request
   4.

   Java 11 deployments
   5.

   WCS version negotiation
   6.

   OGC API Features updates
   7.

   Large catalogs and home page selectors

Actions

   -

   Ask for release volunteers on email list, as applicable (may be
   worthwhile asking for RC volunteers early)
   -

   jody: osgeo budget request

GeoServer release schedule

   -

   Jody and Andrea got the last one out (thanks)
   -

   Ian and Andrea will do the January release 2.22.1
   -

   https://github.com/geoserver/geoserver/wiki/Release-Schedule
   -

      Feb 18 maintenance release needs volunteer
      -

      March 3rd release candidate should have several volunteers due to
      build server and blog post of new features
      -

      March 18th release is Java 11 (Java 17 not confirmed without QA
      commitment)


Send to email list for discussion, jody volunteers to do Feb release or
March RC as

needed



Spring upgrade

Joseph miller been working on this:

   -

   https://github.com/GeoWebCache/geowebcache/pull/1111
   -

   https://github.com/geoserver/geoserver/pull/6515


ContentNegotiationConfigurer.favorPathExtension is deprecated (and no
longer the default configuration) because Spring wants to discourage
extensions in paths.


   1.

   Rest API dispatch depends on this - how to preserve for roadmap?


   -

   Discussion recommends we make our own resolver.
   -

      There’s an (old and primitive) implementation of something like this
      here, that may provide a starting point:
      https://github.com/planetlabs/stratus/blob/master/src/stratus-application/src/main/java/stratus/config/CommunityRestMvcConfigurer.java#L107-L140
      -

   OGCAPI does not use extensions (yet …)


   1.

   Servlet inputstream / outputstream have new methods, so work to update
   mocks etc..
   2.

   Spring started added charset to mime types text/html;charset=utf8
   (correct but annoying). Tests updated to only check first part
   3.

   Spring deprecating spring-remoting (spring 5 deprecated, spring 6
   removed). This is a challenge for geofence.
   4.

   ogcapi modules updated fine (that was unexpected)
   5.

   Spring Security OAuth modules (cleaned up, but makes use of deprecated
   api)
   1.

      manual testing is going ahead to confirm this still works
      2.

      at somepoint (when these go supported) migration to spring-security
      ouath (which will be hard due to final classes) as the spring oauth
      extension is end of life and deprecated


We want to merge as soon as possible; so that this is inplace for March RC.
Soft goal will be to test the community modules mentioned above before
March release (not a requirement).

This PR is Spring 5.2 -> 5.3.23, the latest is 5.3.25 (which was released
during this activity)

Spring 6 will be more extensive update (Spring 5 EOL is end of 2024)
OSGeo Budget request

Deadline is Jan 20th for funding requests, see technical debt page for
funding request across projects.

Jan 30th board meeting
<https://wiki.osgeo.org/wiki/Board_Meeting_2023-01-30>

   -

   need a volunteer to attend, discuss org.opengis topic
   -

   removing the org.opengis
   <https://git.osgeo.org/gitea/osgeo/todo/issues/142> (see here for budget
   estimate)

Jan 20th Board Funding deadline (this friday)

   -

   We need to write a wiki page, and email osgeo board
   -

   We did benefit from OSGeo funding last year; would be good to apply again
   -

      Jody volunteered, need a review (multiply numbers by 2)
      -

   Example:
   https://github.com/geotools/geotools/wiki/GeoTools-Budget-Request-2022


Some email discussion:

   1.

   replace org.opengis packages (if OSGeo / Apache provides funding to so)
   1.

      mixed response from email list
      2.

      https://github.com/geotools/geotools/wiki/Remove-OpenGIS
      1.

         We can discuss another time, there is an interesting trade off if
         you read the API Change (with two ideas)



   1.

   Idea: Ask OSGeo to set up a security emergency funding that projects
   could apply for similar to code-sprint


Need a volunteer to attend OSGeo Meeting.

Java 11 deployments to OSGeo repo

Jenkins 11 builds were isolated, and do not deploy to osgeo nexus (may wish
to keep for Java 17 isolated testing)

For main we may wish to copy the old builds, and change the JDK for 11? Or
just copy the deploy step …


   1.

   Copy Java11 main builds to Java 17 main builds (and disable)
   2.

   Edit Java 11 builds to remove local workspace m2 repo (remove
   -Dmaven.repo.local flag)
   1.

      Also remove the actual workspace folder in General Settings (need to
      click “Advanced”):
      2.

      This may also require adjusting -DconfigDirectory=../../../data in
      the geoserver builds
      3.

   Edit Java 11 builds to add deploy step (may need to add some OSGeo nexus
   secret)


→ Devel series Java 11 builds hopefully fixed during the meeting
WCS version negotiation

PR https://github.com/geoserver/geoserver/pull/6430


   -

   Good approach, shows some weakness in dispatcher, opens up more ideas
   than budget :)
   -


OGC API Features updates

goal: pass core and crs tests

   1.

   Stick a version number in the API path (breaking change)


   -

   this is an unsupported module have fun


   1.

   Include version in headers, non breaking change
   2.

   The open api url is at service/api → service/openapi


   -

   this is an unsupported module have fun
   -

   (this would break client code that has been generated again prior api)


   1.

   In ogcapi can have multiple links .. somewhere?


   -

   Used by INSPIRE to link to download, metadata, etc…


   -

   Make a general “add a link” (like metadata links for layers in services,
   capabilities)
   -

   This distinct from existing service and layer facilities that add URLs
   (which are specific to metadata or inspire)


Q: Enable / Disable ogcapi conformance classes?

   -

   Interesting idea? Not sure if it is good idea …
   -

      Simple: Just do not declare (do not advertise GML because ogcapi-core
      demands SF0 if GML is advertised, no ability to support generic GML)
      -

      Implementation: enable filter? Could we turn off CQL2, or filtering
      altogether

Q: Cleanup?

   -

   May be opportunity to remove random ideas from community module (example
   YAML everywhere because it is fun)


IMPORTANT: This does not bring the module up to extension status
Chit/Chat

proof of concept: https://github.com/geoserver/geoserver/pull/6392

Welcome page with large catalogs? Open issue…

   -

   PR shows an viable approach (proof-of-concept)
   -

   minimal: turn off drop down and counts
   -

   stretch: auto-complete improvements (as above proof-of-concepts)
   -

      timebox: Use 200+ if reaches count of 200 in timeout …
      -

   out of scope but interesting
   -

      Security checks really slow this down (welcome page and layer preview
      and getcapabilities unusable with large catalogues and fine
grain security
      checks)


Jody interested in the UI switch proposed in the proof-of-concept