Ian: The remove opengis funding is set-up as a cross project thing (not specifically allocated to a project budget). That said if it does not meet its funding target; or if we cannot attract participants even with money there is no obligation to proceed.
I know my own employer does not see the value (so I will not be working on the activity even with funding...). I may still help out as a volunteer; if only so Andrea can enjoy life. -- Jody Garnett On Mon, May 15, 2023 at 4:03 AM Ian Turton <ijtur...@gmail.com> wrote: > > > On Mon, 15 May 2023 at 11:32, Andrea Aime < > andrea.a...@geosolutionsgroup.com> wrote: > >> Hi all, >> as you probably know, GeoServer has a core dependency on H2 database >> version 1.1.119. >> This is slowly becoming troublesome for a few reasons: >> >> - The 1.x series of H2 is abandoned >> - It's accumulating CVEs, while none of them seems to be affecting >> our current usage, they still show up in all dependencies reports >> >> So it would be a good idea to upgrade. H2 version 2 is supported, but it >> poses serious upgrade problems: the format of the database changed, and H2 >> has no compatibility with 1.x databases. The only way to upgrade is to dump >> SQL using the older version, and then restore with the newer one. >> In addition, H2 retained the same package names, meaning we cannot have >> both in the same classpath (unless we use shading). >> To make things worse, H2 1.x did not have spatial data types, so we have >> WKB stored in the database as binary columns, with spatial indexing >> provided by extra libraries that also happen to be dead (hatbox, geodb). >> >> In GeoSolutions we have been trying to organize an upgrade for a while, >> but it turns out it's too much work to be done in one shot (clear funding >> issue). >> >> However, there is an easier path... chipping away at it a few >> dependencies at a time. Turns out some of the dependencies towards H2 are >> core, and others are in plugins. The one that really need a spatial >> database are just in plugins, while the core dependencies need only an >> alphanumeric database: >> >> - GWC disk quota mechanism >> - KML superoverlay support (is anyone still using it? 😁 >> >> In both cases the databases collect caches of information that can be >> rebuilt automatically by GeoServer as needed, so no actual migration >> procedure is needed: we can drop the old database, and start over with a >> new one. >> >> Disk quota over H2 is not recommended for production environments, but >> still, to keep our "ease of use" story going, having an embedded database >> would be a good thing. >> >> So what we propose is easy: for these two use cases we switch the >> embedded database usage to HSQL, which has been modestly, but steadily, >> serving our CRS database needs for years, without causing trouble. It's >> already in our classpath, it has been used for a long time, it's pure java, >> and it's small (1.6MB). >> >> Alternatives considered and discarded for the task at hand: >> >> - Sqlite/Geopackage: the sqlite jdbc library is a beast (12.2 MB and >> growing) and not part of the GWC dependencies. >> - H2 v 2.x, because it would mean shading it and right now we'd have >> to either shade all other usages of 1.x (can't cover that) or shade 2.x >> (which is the opposite of the direction we're going) >> >> Removing the need for H2 In the core will also allow the possibility of >> running GeoServer along with the H2GIS data store (that already depends on >> H2 v 2.x). The other places where we need an embedded spatial database may >> be covered, in time, by GeoPackage, until we can wave goodbye to the last >> usage of H2 v 1.x, but they will be doable one by one and at their own >> pace: GeoFence, NetCDF store. >> >> Other non spatial cases that are in plugins, which might be migrated >> later to either GeoPackage or HSQLDB, are wps-jdbc and importer-jdbc (both >> depending on the DataStore interface) and jdbcstore/jdbcconfig. >> >> One thing that will eventually have to go is the H2 datastore we offer as >> an extension. I don't think it has any traction, but we use it for some >> tests. I'd suggest we start removing it from the downloads, though. >> >> Feedback/opinions? W'd like to start migrating GWC and KML substystem as >> soon as possible. >> >> And oh, I started a mail discussion rather than writing a proposal >> because there is one bit in here that is totally against the proposal >> requirements: having a fully funded plan. What we can offer is a >> vision/direction and a first stepping stone, but we won't be able to cover >> the full elimination of H2 v1.x (as said, too much work to fund it in one >> shot, and a small audience of interested parties). >> > > All this sounds great, my only passing thought re funding is that this is > probably a better use of our osgeo funding than removing opengis but I > don't know if we could swap out the end goal of that funding. Is this > something we could do in a weekend code sprint in say Kosovo? > > Ian > >> >> Cheers >> Andrea >> >> == >> >> 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 >> _______________________________________________ >> Geoserver-devel mailing list >> Geoserver-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> > > > -- > Ian Turton > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel >
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
