GeoTools / GeoServer PMC meeting - 2025-04-22Attending
* - Torben Barsballe- Andrea Aime- Kevin Smith- Jody Garnett- Gabriel Roldan*Actions from prior meetings: * - [image: non selezionata]gabe: some small update for dev guide, updating conf.py by hand no longer needed- [image: non selezionata]Discuss var and lombok next time- [image: non selezionata]Volunteer needed: postgis testing github workflow action- [image: selezionata]aaime: geoserver-release-docker add docker prune - check in next week to see if it’s working- https://build.geoserver.org/view/release/job/geoserver-release-docker/1823/console <https://build.geoserver.org/view/release/job/geoserver-release-docker/1823/console> reclaimed 1.2 GB, looks like its working- [image: selezionata]Torben: Ask on Dev list if others use components*Agenda * - GeoServer 3- CITE and funding- GeoServer LTS- var and lombok*Actions * - [image: non selezionata] *GeoServer 3 *Crowdfunding Phase 1 complete (pledge), time to move phase 2 (collection and actual working on GeoServer 3).Thanks everyone so much for your support! We have met our funding target to start GeoServer 3 development in May! More funds are still very much appreciated and will be used to achieve more.Stay tuned, we are very excited!So where to start. Milestone 1 goals are ready to be worked: 1. ImageN is the top priority and we are looking at an online sprint the last week of May. The project will need to be restarted ahead of the sprint to ensure everyone available has access to the codebase. Jody will be taking point on restarting the project, as Andrea pulls together the plan of what is needed where. We intend to use github project board. May 26-May 30th online ImageN sprint2. We are really looking forward to catching up OAuth2 work at the start of May. Very thankful to Andreas Watermeyer to create the new modules and we plan to integrate them in the code base. See also https://github.com/geoserver/geoserver/pull/7968 <https://github.com/geoserver/geoserver/pull/7968>We’ll also need to look at the new developments in the old OAuth2 modules.3. Gabe is ready to start on project and build support, including setting up a geotools bill-of-materials to help make upgrading dependencies easier across the project status. While we were very successful writing refactoring scripts with ant for the OpenGIS Harmonization … it was labour intensive. This time Gabe will be looking at open rewrite scripts for GeoTools update.. Potential recipe here <https://docs.openrewrite.org/running-recipes/popular-recipe-guides/migrate-to-java-17>. General approach: We are going to do as much milestone 1 work in GeoServer 2.28 as we can.We will make a dev branch for GeoServer 3 during milestone 2 (when we freeze the codebase).*CITE and funding *CITE certifications cost based on size of organization <https://www.ogc.org/how-our-compliance-program-works/> ($25k to $600) … OSGeo agreement has negotiated the lower “member” cost of $150. This is for an “annual license fee” of the CITE sticker and words.Standards we’d have to pay for ($150 for each): - GeoPackage 1.2- WMS 1.1.1- WMS 1.3.0- OGC API - Features 1.0- WFS 1.1.0- WFS 2.0We have several options for CITE certification now that we pass tests! - Option: $450 to be certified on the important standards WMS 1.3.0, WFS 2.0, and OGC API - Features - Option: $900 for GeoServer 2.27.0 certification of everything we have passing added GeoPackage, WMS 1.1.1, WFS 1.1.0Q: CITE is an annual certification, but we plan two major releases a year? Not sure what that means for costs…Annual cost? OSGeo wiki talks about it <https://wiki.osgeo.org/wiki/OGC_Certification_Services>.Q: How to reduce costs?Be a reference implementation; so can try to prioritize.Q: Do we have money?Yes, from prior sponsors. But we should be upfront with our community that if this has value we need funding for this activity as it is not free.action: - [image: non selezionata]jody: Invite Angelous to next GeoServer meeting to ask questions, and ask the questions above.*GeoServer LTS *Idea: - Have an LTS that lives 2 years- Make this in line with Java release model…- Java 17 release in 2021- Java 21 release in 2023- And and EU Cyber Resilience acts and so on ..- Have a short lived release every 6 months, that will live only those six months- Alternate release:- One month LTS- The next month the short lived release- RepeatFeedback: - This would reduce backports of “new functionality” and may slow down the entire pace of the project- new extension kind of thing is easy to backported this would need to be emphasis for development going forward- but changes to core are harder to backported without affecting stability- If we only had security updates backported, would not expect people to use the LTS- But security updates like a wicket upgrade would not be possible to backport without touch stability*var and lombok var is fun to write, but harder to read, why did they do this to us! - Can we get rid of var? Yes there is a PMD rule <https://pmd.github.io/pmd/pmd_rules_java_codestyle.html#useexplicittypes>, but we should talk before enforcing this (the rule just reduces use, but allows for literals and collections where it is very clear) - Java style guideline for java <https://openjdk.org/projects/amber/guides/lvti-style-guide> has a good discussion, accept that this relaxes the code to interface idea, since this is a local variable. warning: if you start adopting type of variable in the variable name you have gone too far! - So what is the problem, when using var to define a local variable from a method call .. can be very difficult to understand what object you ended up with. Q: Have we tested the PMD rule? Use ExplicitTypes rule would pass just fine, we only have a dozen case in GeoSever. OpenRewrite transforms would introduce var in lots of places: - introduce var for referenced typed variables - introduce var for local primitive is more problematic - it’s a case by case situation that would have different developers decide in different ways. Problematic for PR review GeoServer Cloud uses it? - Gabe was surprised to see 90 uses… agrees not suited for a project with many committers Action: - [image: non selezionata] aaime: Make a PR for the PMD rule above forbidding usage of var, and update the style guide lombok project <https://projectlombok.org>: - quick way to make beans using annotations - getters and setters - equals and hashcode (actually of benefit as it notes new fields) - others are trouble: var and val - vastly reduces use of boilerplate code - geonetwork 5 codebase is much better because of use of lombok reducing lots of boilerplate code - careful: did have some poor interaction between generated getters and setters and PMD rules checking generated bytecode (requires PMD 7 recent releases) - idea: whitelist annotations that we want to use, forbid others Approach: just allow it, or start doing as a migration.
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
