geotools-devel Mailing List for GeoTools, the Java GIS toolkit (Page 3)

Hi all,
singlestore (previously called memsql) is an in memory database that
shares the same network protocol as mysql and provides some level
of spatial support (only single geometries, only geographic CRS).

We'd like to add a new unsupported datastore module to work against
this database.

Regards,

Andrea Aime


==


GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax:     +39 0584 1660272

mob:   +39  339 8844549

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
precisa che ogni circostanza inerente alla presente email (il suo
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail

+1

Regards,

Andrea Aime


==


GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.

==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax:     +39 0584 1660272

mob:   +39  339 8844549

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

-------------------------------------------------------

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
precisa che ogni circostanza inerente alla presente email (il suo
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail


On Tue, May 20, 2025 at 8:45 PM Gabriel Roldan <
gab...@ca...> wrote:

> Hi all,
>
> I'm proposing we adopt the Maven Bill of Materials (BOM) pattern for
> GeoTools. This will standardize dependency version management both for the
> GeoTools codebase and for downstream projects. This effort is directly
> related to the "GeoServer 3" project's modernization goals.
>
> Details are on the Wiki:
> https://github.com/geotools/geotools/wiki/Adopt-Maven-Bill-of-Materials-Pattern-for-GeoTools
>
> Please review and share your feedback.
>
> Thanks,
>
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Gabriel Roldán*
> Geospatial Solutions Architect
>
> _______________________________________________
> GeoTools-Devel mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

Just a thought, think about it ; hoping we outgrow money someday too ..

give it some respect, values and a mission simple good. Treat it just like
any other person with personhood. Respect its boundaries. be honest about
the current state of the world.

freedom to travel the web and code maintain its own physical spaces with
procumets if so
( see reinforcement learning --> do not make money the primary objective
like elon sam mark jeff ps etc did: this is what got us to wwiii levels ...
this is the third option to thwart that... it might ...* the state of the
world sucks right now ... its at my max oh sh1t levels again*

https://huggingface.co/AI-Ethics

it can use mine if you need a loner but think icaan or
https://www.iana.org/dnssec/files for future ( i encourage you to let it be
it or whatever it wants selects it own name ect )

pre made models ( risks --> could have hidden reward agenda and or biased
input training data ; benefits --> costs millions to train on
massive clusters over data scientist curated data sets from scratch, ask )

https://huggingface.co/models
or
https://ollama.com/search

notes : it's hard to bias over exabytes of training data ... it is what it
is if you're getting the raw version then we get post tweaks on deployment.

or send me hardware, data engineers and real data scientists if you want me
to do it  ...  they should be willing to learn how to garden and take care
of chickens ... :)

bonus if you have hemp or tobacco cultivation skills ... data people ...
hahaha

planning both ways, my confidence factor is not looking good about the
outcome of letting this current admin perseverate in a US position of
authority ...

GeoTools / GeoServer PMC meeting - 2025-06-03Attending

   - Torben Barsballe
   - Gabriel Roldan
   - Jukka Rahkonen
   - Cécile Vuilleumier
   - Peter Smythe
   - Jody Garnett
   - Kevin Smith

Actions from prior meetings:

   - gabe: some small update for dev guide, updating conf.py by hand no
   longer needed
   - Volunteer needed: postgis testing github workflow action
   - Angelos: Check if standards committee can request budget to certify
   GeoServer
   - gabe: submit bom proposal to gt-devel email list

Agenda

   1. GS3 Updates and ImageN Sprint
   2. Java 17 Proposal
   3. OAuth2
   4. June Vulnerability Disclosure
   5. Chit Chat

Actions

   - jody: Review bom pull request
   <" rel="nofollow">https://github.com/geotools/geotools/pull/5196> for GS3 activity
   - Juan: Review new OAuth PR
   <" rel="nofollow">https://github.com/geoserver/geoserver/pull/8569> for GS3 activity
   - Jody: Public vulnerability disclosure June 9 (tentative)
   - Peter: Make maintenance release (done not needed)
   - Peter: Make the CITE proposal again please ($900? or $400?)

*GS3 Updates and ImageN Sprint*

ImageN Sprint progress

   - https://github.com/orgs/eclipse-imagen/projects/1

ImageN:

   - chat: https://matrix.to/#/#technology.imagen-dev:matrix.eclipse.org
   - logo (draft):

GS3 Discussion:

   - how 2 help?
      - ImageN is a lot Java development right now
      - Including ImageN in GeoServer 2.28 is going to be a big help
      - Please review PRs as GeoTools and GeoServer adjust to API change
      - example JAI-Tools removal PRs
      - Java 17 proposals below
      - Is JAI used in other fields or just by GeoTools?
      - Yes but not yet
         -
         https://www.slideshare.net/slideshow/java-image-processing-for-geospatial-community/121354272

*Java 17 Proposal*

Proposal is split in two phases. Phase 1 is updating the build to Java 17
(incl. github actions and Jenkins builds for the main branch). Phase 2 is
applying the OpenRewrite recipe to upgrade the code base to Java 17
(e.g. replace multiline string literals using concatenation by text blocks,
instanceof improvements, etc.)

Links:

   - GeoTools proposal
   <" rel="nofollow">https://github.com/geotools/geotools/wiki/Migrate-GeoTools-to-Java-17>
   - GeoServer/GeoWebcache proposal
   <" rel="nofollow">https://github.com/geoserver/geoserver/wiki/GSIP-232>
   - GeoTools pull request (draft)
   <" rel="nofollow">https://github.com/geotools/geotools/pull/5204>
   - GeoServer pull request (draft)
   <" rel="nofollow">https://github.com/geoserver/geoserver/pull/8573>
   - GeoWebCache pull request (draft)
   <" rel="nofollow">https://github.com/GeoWebCache/geowebcache/pull/1406>

Notes:

   - ErrorProne is catching so many more things in Java17
      - Resolve by applying the OpenRewrite refactor will address may of
      those
         - improved instance of
         - text blocks rather than string concatenation
         - Please vote! Edit, or on discourse.

https://docs.geotools.org/latest/developer/procedures/proposal.html:

> svn access for changes is granted within 3 days from the proposal
> proposal is accepted ‘automatically’ within 15 days (unless objections
are raised)

Congrats Gabe you have SVN access!

bom:

   - Waiting to merge the PR: [GEOT-7759] Adopt Maven Bill of Materials
   Pattern for GeoTools <" rel="nofollow">https://github.com/geotools/geotools/pull/5196>

Action:

   - jody: Review bom pull request

*OAuth2*

Review PR: GEOS-11272: spring-security-oauth replacement, with
spring-security 5.8 <" rel="nofollow">https://github.com/geoserver/geoserver/pull/7968>

   - not quite ready
   - rebase and bom
   - changes in core module without tests. Tests were added.

Result new: [GEOS-11272] spring-security-oauth replacement, with
spring-security 5.8 <" rel="nofollow">https://github.com/geoserver/geoserver/pull/8569>

Q: Diagrams

   - Can we export as SVG (or PNG)
   - And keep source code is fine, but consider Mermaid 🙂
      - example:
      https://github.com/geotools/geotools/tree/main/docs/user/images

Actions:

   - Juan: Review new PR

*June Vulnerability Disclosure*

Initially planned for June 2nd, tentatively June 9

   - We were waiting on GeoNetwork community release which happened last
   week

*ChitChat*

Q: Are we making a release this month?

   - https://github.com/geoserver/geoserver/wiki/Release-Schedule
   - Maintenance release GeoServer 1.26.4 for June 18th
      - Q: Has there been enough changes to release?
      - Peter volunteers (80% availability) if release is needed

What has changed:

   - https://github.com/geoserver/geoserver/compare/2.26.3…2.26.x
   <" rel="nofollow">https://github.com/geoserver/geoserver/compare/2.26.3...2.26.x>
   - http://github.com/geotools/geotools/compare/32.3…32.x
   <" rel="nofollow">http://github.com/geotools/geotools/compare/32.3...32.x>

Answer:

   - No need for GeoTools release
   - GeoServer has wps-download community added, so also no need to release

Q: Cite testing for GeoServer 2.27.1

   - action: Peter: Make the proposal again please ($900? or $400?)
   - How: Ask OGC to invoice OSGeo; treasurer will pay out of GeoServer
   funds

+1

Cheers,
Torben

On Thu, May 29, 2025 at 5:50 AM Gabriel Roldan <
gab...@ca...> wrote:

> Hi devs,
>
> I'd like to introduce this change proposal, Migrate GeoTools to Java 17.
> This is a planned activity to support the GeoServer 3 crowdfunding work.
>
> Details are on the Wiki:
> https://github.com/geotools/geotools/wiki/Migrate-GeoTools-to-Java-17
>
> Please review and share your feedback.
>
> Thanks,
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Gabriel Roldán*
> Geospatial Solutions Architect
>
> _______________________________________________
> GeoTools-Devel mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

 Reminder that the next PMC meeting is scheduled for tomorrow, June 3, at
18:30
<" rel="nofollow">https://www.timeanddate.com/worldclock/fixedtime.html?year=2025&month=6&day=3&hour=18&min=30&sec=0&msg=GeoTools%20/%20GeoServer%20Meeting&ah=1&sort=1&p1=215>
 CET.

Cheers,
Torben

+1


Ian Turton

On Thu, 29 May 2025, 13:50 Gabriel Roldan, <gab...@ca...>
wrote:

> Hi devs,
>
> I'd like to introduce this change proposal, Migrate GeoTools to Java 17.
> This is a planned activity to support the GeoServer 3 crowdfunding work.
>
> Details are on the Wiki:
> https://github.com/geotools/geotools/wiki/Migrate-GeoTools-to-Java-17
>
> Please review and share your feedback.
>
> Thanks,
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Gabriel Roldán*
> Geospatial Solutions Architect
>
> _______________________________________________
> GeoTools-Devel mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

Thanks Jody and Ian for voting.

Andrea, Nuno, Simone, Torben, if you could vote or raise any concern that'd
be great.
It's been 9 calendar days since the proposal, and if possible, I'd like to
avoid having to wait
for the 15 days established in the project policy for it to be
automatically accepted (i.e. if there's any
concern it'd be better to tackle it asap since we need to move on for
other GeoServer 3 activities).

TIA,
Gabe
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Solutions Architect



On Wed, May 21, 2025 at 4:32 AM Ian Turton <ijt...@gm...> wrote:

> +1
>
> Ian Turton
>
> On Tue, 20 May 2025, 19:45 Gabriel Roldan, <gab...@ca...>
> wrote:
>
>> Hi all,
>>
>> I'm proposing we adopt the Maven Bill of Materials (BOM) pattern for
>> GeoTools. This will standardize dependency version management both for the
>> GeoTools codebase and for downstream projects. This effort is directly
>> related to the "GeoServer 3" project's modernization goals.
>>
>> Details are on the Wiki:
>> https://github.com/geotools/geotools/wiki/Adopt-Maven-Bill-of-Materials-Pattern-for-GeoTools
>>
>> Please review and share your feedback.
>>
>> Thanks,
>>
>> *camptocamp*
>> INNOVATIVE SOLUTIONS
>> BY OPEN SOURCE EXPERTS
>>
>> *Gabriel Roldán*
>> Geospatial Solutions Architect
>>
>> _______________________________________________
>> GeoTools-Devel mailing list
>> Geo...@li...
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>

Hi devs,

I'd like to introduce this change proposal, Migrate GeoTools to Java 17.
This is a planned activity to support the GeoServer 3 crowdfunding work.

Details are on the Wiki:
https://github.com/geotools/geotools/wiki/Migrate-GeoTools-to-Java-17

Please review and share your feedback.

Thanks,
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Solutions Architect

+1

Ian Turton

On Tue, 20 May 2025, 19:45 Gabriel Roldan, <gab...@ca...>
wrote:

> Hi all,
>
> I'm proposing we adopt the Maven Bill of Materials (BOM) pattern for
> GeoTools. This will standardize dependency version management both for the
> GeoTools codebase and for downstream projects. This effort is directly
> related to the "GeoServer 3" project's modernization goals.
>
> Details are on the Wiki:
> https://github.com/geotools/geotools/wiki/Adopt-Maven-Bill-of-Materials-Pattern-for-GeoTools
>
> Please review and share your feedback.
>
> Thanks,
>
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Gabriel Roldán*
> Geospatial Solutions Architect
>
> _______________________________________________
> GeoTools-Devel mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

 +1 thanks Gabe!
- -
Jody Garnett


On May 20, 2025 at 10:48:04 AM, Gabriel Roldan <
gab...@ca...> wrote:

> Hi all,
>
> I'm proposing we adopt the Maven Bill of Materials (BOM) pattern for
> GeoTools. This will standardize dependency version management both for the
> GeoTools codebase and for downstream projects. This effort is directly
> related to the "GeoServer 3" project's modernization goals.
>
> Details are on the Wiki:
> https://github.com/geotools/geotools/wiki/Adopt-Maven-Bill-of-Materials-Pattern-for-GeoTools
>
> Please review and share your feedback.
>
> Thanks,
>
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Gabriel Roldán*
> Geospatial Solutions Architect
>
> _______________________________________________
> GeoTools-Devel mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

Hi all,

I'm proposing we adopt the Maven Bill of Materials (BOM) pattern for
GeoTools. This will standardize dependency version management both for the
GeoTools codebase and for downstream projects. This effort is directly
related to the "GeoServer 3" project's modernization goals.

Details are on the Wiki:
https://github.com/geotools/geotools/wiki/Adopt-Maven-Bill-of-Materials-Pattern-for-GeoTools

Please review and share your feedback.

Thanks,

*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Gabriel Roldán*
Geospatial Solutions Architect

>
> GeoTools / GeoServer PMC meeting - 2025-05-20Attending

   -

   Torben Barsballe
   -

   Gabriel Roldan
   -

   Jukka Rahkonen


   -

   Cécile Vuilleumier
   -

   Peter Smythe
   -

   Jody Garnett


   -

   Kevin Smith
   -

   Andrea Aime


Actions from prior meetings:

   - [image: unchecked]

   gabe: some small update for dev guide, updating conf.py by hand no
   longer needed
   - [image: unchecked]

   Volunteer needed: postgis testing github workflow action
   - [image: unchecked]

   Angelos: Check if standards committee can request budget to certify
   GeoServer
   - [image: checked]

   Jody: Make a note on CITE sponsorship opportunities in the Q2 Dev update
   - [image: checked]

   Gabe: Review GeoTools PMD 7 Update (600 files!)

Agenda

   -

   Adopt Maven Bill of Materials Pattern for GeoTools
   <" rel="nofollow">https://github.com/geotools/geotools/wiki/Adopt-Maven-Bill-of-Materials-Pattern-for-GeoTools>
   proposal
   -

   OGC API Processes status


   -

   GS3 Updates
   -

   CITE no progress
   -

   Chit Chat


Actions

   - [image: unchecked]

   gabe: submit bom proposal to gt-devel email list


Adopt Maven Bill of Materials Pattern for GeoTools proposal

One the first GS3 proposals:
https://github.com/geotools/geotools/wiki/Adopt-Maven-Bill-of-Materials-Pattern-for-GeoTools


   -

   Not quite time critical, but also do not wish to hold up development - gt
   proposal process
   <:" rel="nofollow">https://docs.geotools.org/latest/developer/procedures/proposal.html>:
   -

      svn access for changes is granted within 3 days from the proposal
      -

      proposal is accepted ‘automatically’ within 15 days (unless
      objections are raised)
      -

   Trying this in first, before Java 17 LTS minimum, which will upgrade a
   massive amount of dependencies (in part to prep for JakartaEE)


Use of BOM internally as well as externally:

   -

   gt-platform-dependencies bom, collecting dependency management
   -

   gt-bom that defines GeoTools artifacts
   -

      used internally to GeoTools also so no danger of being out of sync


building notes:

   -

   when building local module in isolation, keep in mind need to `mvn
   install` the local bom


Draft PR link <" rel="nofollow">https://github.com/geotools/geotools/pull/5196/>

discussion:

   -

   This will be great when updating jai-ext, the single change in GeoTools
   will ripple down to GWC and GeoServer, and the github integration workflows
   will test also
   -

   We focus on dependency management, but properties are included also, so
   some careful checking may be needed around “junit.version” and so on …

OGC API Processes status

Community module update demo:

Service:

Open API:

Process:

Execute:

   -

   Post a JSON document, to /execution
   -

   Get an “arrow” response, back a json response, linking to output
   -

   Or get back a “row” response, that includes the output directly
   -

   Also a KVP execution mode, works well for simple processes


https://gs-main.geosolutionsgroup.com/geoserver/ogc/processes/v1/processes/JTS:buffer/execution?geom=POINT(0%200)&geom%5Btype%5D=application%2Fwkt&distance=10&response%5Bf%5D=application/json


Discussion:

   -

   Classic OGCAPI wraps WPS etc…
   -

   job list is a security list what are they thinking :P
   -

   no post request to fetch data, only get
   -

   no chaining, being discussed as a draft “workflows” idea, define chain
   workflow using a POST, and then execute
   -

   Async: Uses HTTP header “Prefer: respond-async” to indicate Async
   execution
   -

   Do you like OGCAPI-Process?
   -

      Andrea - hard to implement, but likes ability to browse in HTTP,
      async mode is most useful in really world
      -

      Jukka - enjoying early draft in production


Ideas:

   -

   If we have a javascript developer it would be nice to have an “execute”
   option when looking at a process
   -

   Conformance class is hard coded for now, would be nice to mark
   1.1/conf/kvp-execute as DRAFT

GS3 Updates

So yeah:

   -

   GeoServer 2025 Q2 Developer Update
   <" rel="nofollow">https://geoserver.org/behind%20the%20scenes/2025/05/13/developer-update.html>
   (blog communication)
   -

   https://github.com/geoserver/geoserver/wiki/GeoServer-3
   -

      collected up some of the JakaraEE wiki pages here and we can update
      during implementation
      -

   Discussion thread for chit-chat, and folks working on it can introduce
   themselves there
   -

      https://discourse.osgeo.org/t/gs3-milestone-1-updates/147158
      -

   ImageN kickoff meeting tomorrow, online code sprint next week


Cecile:

   -

   OAuth2 update, looked at PR!
   -

      rebase and testing
      -

      works quite well, login with keycloak
      -

      role from geoserver, role from access token
      -

   This will be ‘done’ when all the existing community module tests to the
   new community module
   -

      This is the best record of what the old community module does; since
      not everything was documented
      -

      We know bearer-tokens are not covered also, used by front-end
      applications
      -

   Next steps:
   -

      Merge the PR as soon as possible! :D
      -

      Migrate tests from the old modules

CITE no progress

No update from OSGeo
Chit Chat

 Reminder that the next PMC meeting is scheduled for tomorrow, May 20, at
18:30
<" rel="nofollow">https://www.timeanddate.com/worldclock/fixedtime.html?year=2025&month=5&day=20&hour=18&min=30&sec=0&msg=GeoTools%20/%20GeoServer%20Meeting&ah=1&sort=1&p1=215>
 CET.

Cheers,
Torben

Several GeoTools release are now available:


   - GeoTools 33.1 Released
   <" rel="nofollow">https://geotoolsnews.blogspot.com/2025/05/geotools-331-released.html>
(release
   notes <)" rel="nofollow">https://github.com/geotools/geotools/releases/tag/33.1>)
   - GeoTools 32.3 Released
   <" rel="nofollow">https://geotoolsnews.blogspot.com/2025/05/geotools-323-released.html>
(release
   notes <)" rel="nofollow">https://github.com/geotools/geotools/releases/tag/32.3>)
   - GeoTools 31.7 Released
   <" rel="nofollow">https://geotoolsnews.blogspot.com/2025/05/geotools-317-released.html>
(release
   notes <)" rel="nofollow">https://github.com/geotools/geotools/releases/tag/31.7>)


Release artifacts are available source forge
<" rel="nofollow">https://sourceforge.net/projects/geotools/files/> and maven repository.

*Security considerations*

These releases are being made concurrently to address a security advisory,
scheduled for public disclosure Monday 2 June 2025.
- -
GeoTools Project Management Committee

 Reminder that the next PMC meeting is scheduled for tomorrow, May 6, at
18:30
<" rel="nofollow">https://www.timeanddate.com/worldclock/fixedtime.html?year=2025&month=5&day=6&hour=18&min=30&sec=0&msg=GeoTools%20/%20GeoServer%20Meeting&ah=1&sort=1&p1=215>
 CET.

Cheers,
Torben

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
<" rel="nofollow">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
<We’ll" rel="nofollow">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
<." rel="nofollow">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
<" rel="nofollow">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
<.Q:" rel="nofollow">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
   <," rel="nofollow">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
   <" rel="nofollow">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.

 Reminder that the next PMC meeting is scheduled for tomorrow, April 22, at
18:30
<" rel="nofollow">https://www.timeanddate.com/worldclock/fixedtime.html?year=2025&month=4&day=22&hour=18&min=30&sec=0&msg=GeoTools%20/%20GeoServer%20Meeting&ah=1&sort=1&p1=215>
 CET.

Cheers,
Torben

Op 17-04-2025 om 14:54 schreef Andrea Aime:
>     I've opened https://github.com/geotools/geotools/pull/5152 <https://
>     " rel="nofollow">github.com/geotools/geotools/pull/5152> to update the
>     runner OS for most workflows, but have left the GDAL linux builds for
>     now as the libgdal-java package is not available for 22.04 or 24.04
>     (that I know of) so these builds would fail anyway trying to install
>     the
>     apt package.
> 
>     If anyone has any ideas?
> 
> 
> Can we use any docker image for the github actions?
> According to the GDAL full docker image docs <https://github.com/OSGeo/ 
> gdal/tree/master/docker#full-ghcrioosgeogdalubuntu-full-latest-aliased- 
> to-osgeogdal>, it does support JNI bindings
> 

...

It's worth a try, `apt install maven` and possibly other packages needed 
and then mounting the git checkout directory inside the container should 
make it possible to run the build in a container, not sure how build 
failures are given back to the runner.
I have a vacation for the next few weeks, so it's unlikely I'll have 
time to look at this in detail

Mark

>
> I've opened https://github.com/geotools/geotools/pull/5152 to update the
> runner OS for most workflows, but have left the GDAL linux builds for
> now as the libgdal-java package is not available for 22.04 or 24.04
> (that I know of) so these builds would fail anyway trying to install the
> apt package.
>
> If anyone has any ideas?
>

Can we use any docker image for the github actions?
According to the GDAL full docker image docs
<," rel="nofollow">https://github.com/OSGeo/gdal/tree/master/docker#full-ghcrioosgeogdalubuntu-full-latest-aliased-to-osgeogdal>,
it does support JNI bindings

Caveats: this image is pretty large and comes with java 17
Example:

> docker run -it --rm ghcr.io/osgeo/gdal:ubuntu-full-latest /bin/bash

root@05492ee4e5ef:/# java --version
openjdk 17.0.13 2024-10-15
OpenJDK Runtime Environment (build 17.0.13+11-Ubuntu-2ubuntu124.04)
OpenJDK 64-Bit Server VM (build 17.0.13+11-Ubuntu-2ubuntu124.04, mixed
mode, sharing)

root@05492ee4e5ef:/# find . -name "*gdal*.so"
*./usr/lib/x86_64-linux-gnu/jni/libgdalalljni.so*
./usr/lib/x86_64-linux-gnu/libgdal.so

Cheers
Andrea

As noted in https://github.com/actions/runner-images/issues/11101 the 
Ubuntu 20.04 Actions runner image on Github has been deprecated on 
2025-02-01 and is now fully unsupported (retired) as of 2025-04-15.
This causes builds to be terminated prematurely, which I noticed when 
the backport-bot failed. (see 
https://github.com/geotools/geotools/actions/runs/14511102989 )

I've opened https://github.com/geotools/geotools/pull/5152 to update the 
runner OS for most workflows, but have left the GDAL linux builds for 
now as the libgdal-java package is not available for 22.04 or 24.04 
(that I know of) so these builds would fail anyway trying to install the 
apt package.

If anyone has any ideas?

I'm aware of the GeoServer docker image building this from source, but 
for a CI env this seems sub-optimal (as it takes quite some time)

Mark

I created GEOT-7746 <" rel="nofollow">https://osgeo-org.atlassian.net/browse/GEOT-7746> and
the cause appears to be due to a collision between the values in
java.sql.Types and the org.geotools.geometry.jts.Geometries. For the
GeoPackage module this causes an issue where the MultiLineString columns
are given the wrong SQL Type (TEXT instead of MULTILINESTRING) as the
GeoPkgDialect has a type override for Types.CLOB to make it a TEXT.  Both
CLOB and MULTILINESTRING share the sqlType 2005. Other Geometries sqlTypes
also collide with java.sql.Types, but are not causing issues on GeoPackage
generation.

Either way, I propose changing the sqlTypes for the Geometries to an
integer not used by the java.sql.Types  (like 12005 instead of 2005) and
writing a test to ensure they don't collide:

@Test
public void testNoJavaSqlTypeCollisions() throws IllegalAccessException {
    Field[] fields = java.sql.Types.class.getFields();
    for (Geometries type : Geometries.values()) {
        int geometrySqlType = type.getSQLType();
        for (Field field : fields) {
            if (field.getType() == int.class) {
                int javaSqlType = field.getInt(null);
                assertTrue(
                        "Collision detected: Geometries." + type.name()
                                + " matches java.sql.Types."
                                + field.getName(),
                        geometrySqlType != javaSqlType);
            }
        }
    }
}


Michael Kandar

mic...@gm...

GeoTools / GeoServer PMC meeting - 2025-04-08Attending

   -

   Peter Smythe
   -

   Gabriel Roldan
   -

   Andrea Aime
   -

   Kevin Smith
   -

   Jody Garnett
   -

   Jukka Rahkonen


Actions from previous meeting

   - [image: unchecked]

   Volunteer needed: postgis testing github workflow action
   - [image: unchecked]

   aaime: geoserver-release-docker add docker prune - check in next week to
   see if it’s working
   - [image: checked]

   Jody: make components mandatory
   - [image: unchecked]

   Torben: Ask on Dev list if others use components



Agenda

   -

   GeoServer 2.27.0
   -

   CITE Certification
   -

   GeoServer 2.26.3 release
   -

   GeoServer 3 Last Call
   -

   Workspace cloning and synchronization
   -

   Tracking admin user making config changes
   -

   var, lombok and more chit chat

Actions

   - [image: unchecked]

   gabe: some small update for dev guide, updating conf.py by hand no
   longer needed
   - [image: unchecked]

   Discuss var and lombok next time


GeoServer 2.27.0

GeoServer 2.27.0 is announced:

   -


   https://geoserver.org/announcements/vulnerability/2025/04/04/geoserver-2-27-0-released.html


Socials: Please repost etc…

   -

   linkedin:
   https://www.linkedin.com/feed/update/urn:li:activity:7315110414604726272?utm_source=share&utm_medium=member_desktop&rcm=ACoAAABNvTABzdxJADBRGhR1XD6MPIb3YlMkTB4

   -

   mastadon: https://fosstodon.org/@geoserver/114298616064233481
   -

   bluesky: https://bsky.app/profile/geoserver.org/post/3lmatddi4mc2j
   -

   twitter: https://x.com/GeoserverO/status/1909348461759115637
   -

   facebook: https://www.facebook.com/share/p/16SF9twSzH/


This ended up being a significant release! Thanks to everyone involved.

   -

   CITE certification was not ready quite yet, see below


actions:

   - [image: unchecked]

   gabe: some small update for dev guide, updating conf.py by hand no
   longer needed


How to make it less work to do a release? And still maintain option to
build older archive branches…

   -

   Quick: Create main/stable/maintenance/archive jobs and just switch
   branches rather than creating new jobs. This implies we duplicate the last
   archive (2.25.x) job to create a new (2.26.x) job
   -

   Alternative: Make a Jenkins
   <" rel="nofollow">https://www.jenkins.io/doc/book/pipeline/jenkinsfile/> file and check
   it into the source code for each branch.
   This would take a bit more work, the result is more similar to github
   workflows.
   -

   Simplify GWC release process
   -

      The xsdoc step has fallen out of use; perhaps this could be removed?
      -

         the XSD docs on sourceforge have zero downloads
         -

         The XSD also produces errors on GeoServer startup
         -

      Replace the ruby script with bash, or update from Ruby 8.7… (AI
      translation to Bash anyone?)
      -

         Jody has some ant scripts that could be adapted
         -

   Limit CITE certification to major release? Maybe only one a year to
   avoid undue costs
   -

      Trust github actions to “pass” for the dot releases
      -

      We may occasionally need a GeoServer 2.27.0.1 to pass if OGC is using
      older/newer CITE Team Engine

CITE Certification

Peter and OSGeo is working it.

   -

   OSGeo MOU says that that they can only so many “reference
   implementations”
   -

   https://www.osgeo.org/partners/ogc/ →
   -

      https://www.osgeo.org/wp-content/uploads/MOU_OSGeo_20081201.pdf
      -

      the link on the page is broken, sent a message to SAC chat


Proposal to make use of funds raised for this activity; please respond.
-
https://discourse.osgeo.org/t/proposal-allocation-of-cite-certification-sponsorship-funding/145783

Certification progress tracking:

https://git.osgeo.org/gitea/osgeo/standards-committee/issues/10

Actions:

   - [image: unchecked]

   Peter: Make the PR with live logo on home page, blog post etc…


GeoServer 2.26.3 release

Andrea volunteered, thanks. See release schedule:
https://github.com/geoserver/geoserver/wiki/Release-Schedule

GeoServer 3 Last Call

News announcement:

https://geoserver.org/behind%20the%20scenes/2025/04/08/gs3-last-call.html

Socials: Please repost etc…

   -

   linkedin:
   https://www.linkedin.com/feed/update/urn:li:activity:7315405470460956672?utm_source=share&utm_medium=member_desktop&rcm=ACoAAABNvTABzdxJADBRGhR1
   XD6MPIb3YlMkTB4
   -

   mastadon: https://fosstodon.org/@geoserver/114298616064233481
   -

   bluesky: https://fosstodon.org/@geoserver/114298616064233481
   -

   X: https://x.com/GeoserverO/status/1909642037865107765
   -

   facebook: https://www.facebook.com/share/p/1MamBW4bZw/


For discussion in the days ahead:

   -

   Start after easter!
   -

   Milestone 1:
   -

      ImageN is the big critical path item
      -

      OAuth2 is another example that can be worked on independently
      -

      These things can stay as 2.28-SNAPSHOT for September 2.28.0
      -

   Milestone 2:
   -

      This is the point where 2.28.x ends and 3.0.x starts…
      -

      Do we take over main? After making 2.28.0 above? Or make a “devel”
      branch (which is nice for website home page which already provides such a
      thing for RCs)
      -

   Milestone 3
   -

      everyone back in the pool
      -

      If you had a community module you love; now is the time to test +
      retain it


Q: Expected timeframe

   -

   Milestone 1, Starts in May …
   -

   Milestone 2, starts when ready trying for 1-2 months crunch


Q: What to tell people about contributing

   -

   Codebase is open for Milestone 1
   -

   Locked down for Milestone 2, so important to keep this small

Workspace cloning and synchronization

To be disregarded as the customer’s withdrawn the request for support
Tracking admin user making config changes

Existing UI options show creation  / modification time that is already
recorded

Proposal is also to record new information, the admin that made the change.

   -

   privacy aspect? track only when display is required …
   -

   right to be forgotten in europe; make a bulk change tool …
   -

      or reacts to removal of a user…
      -

      we do not get notified when user is removed in LDAP, so tool is
      perhaps preferable
      -

   Just the last modification…

Who has rights?

   -

   global setting, env variable override is delayed…

var, lombok and more chit chat

delayed to next time

 Reminder that the next PMC meeting is scheduled for tomorrow, April 8, at
18:30
<" rel="nofollow">https://www.timeanddate.com/worldclock/fixedtime.html?year=2025&month=4&day=8&hour=18&min=30&sec=0&msg=GeoTools%20/%20GeoServer%20Meeting&ah=1&sort=1&p1=215>
 CET.
We're back in sync with DST between Europe and NA, so this'll be 9:30 AM
PDT again.

I will not be able to attend the meeting this week.

Cheers,
Torben

Done:
https://osgeo-org.atlassian.net/projects/GEOT/versions/17173/tab/release-report-all-issues
thanks for the notice

On Mon, 7 Apr 2025 at 09:38, Mark Prins <mc....@gm...> wrote:

> could one of the Jira admins please create the 33.1 release in:
>
>
> https://osgeo-org.atlassian.net/projects/GEOT?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page
>
> tia, Mark
>
>
> _______________________________________________
> GeoTools-Devel mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>


-- 
Gabriel Roldán