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
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
