Attending
Jody Garnett
Torben Barsballe
Andrea Aime
Actions- Torben to check potential missing OGR package
-
Torben will repost PostGIS build failure to email list
-
Andrea will raise Java 11 test tolerance for GeoTools build (done)
-
Jody to take “geoserver security” idea to mailing list
-
Jody will continue to pursue maven repo for GeoTools, has reached out to osgeo projects.
Agenda- Build failures in 2.15.
-
OGR Build Failure
-
App Schema Build Failrure
-
GeoTools Java 11 Failure
-
Sys Admin
-
Security Topics
-
Deprecation effort update
-
GeoTools care and feeding
Build failures in 2.15
PostGIS install has been moved to apollo-slave-01 in advance of apollo-slave-02 being decommissioned.
OGR Build Failure
Due to build server change, new build node has ogr2ogr available (old did not) but missing some library.
App-schema
App-schema postgis also failing, possibly due to the different postgis version
Failed tests: testNestedFilterEncoding(org.geoserver.test.FeatureChainingWfsTest)
testNestedFiltersEncoding(org.geoserver.test.NestedIdSupportTest)
testClientPropertiesFilter(org.geoserver.test.SimpleAttributeFeatureChainWfsTest): expected:<[1]> but was:<[0]>
testNestedFilterEncoding(org.geoserver.test.SimpleAttributeFeatureChainWfsTest): expected:<Filter.INCLUDE> but was:<[ gml:name = GUNTHORPE FORMATION ]>
Updated to same version of PostGIS, so not that…
Action:
- torben will repost to email list
GeoTools Java 11 Test Failures
Caused by a difference in how Fonts are rendered between Java 11 and Java 8. Requires a change in the test tolerance. Do we need Java 11 reference images? Hopefully not as font rendering changes across operating systems.
Action:
- Andrea has relaxed the tolerance 10% … looks ike it now passes
Sys Admin
Build server discussion, reducing to one slave to reduce operation costs.
SAC has changed download.osgeo.org - we use for webdav currently and the maven deploy “wagon” for webdav is unsupported?
Any interest in setting up Nexus or Artifactory?
Action: Jody will continue to pursue maven repo for GeoTools, has reached out to osgeo projects.
Security Topics
Security incoming:
-
Some new reports came in from Gremwell
-
A good idea on one of them
-
Remaining items require funding …
-
GitHub is reporting vulnerabilities in dependencies
How to fund security fixes:
-
Currently depend on custom or product interest in fixing
-
Those reporting bugs show no direct interest in funding fix (they already funded QA check and are thus contributing …)
-
Not sure about “Donation” button for OSGeo or “sprint” style sponsorship
-
Tends to under value open source
-
Treats security like a charity concern rather that than a core value
-
Discussion on how QGIS and SAC does small contracts
-
Check if this interrupts business model for those selling GeoServer support
Action:
-
Jody to take “geoserver security” idea to mailing list
-
Distribute via OSGeo similar to how SAC operates where … available developers is the constraint
-
Adding to “fund” get visibility into security email list as issues are reported
-
Can address via commercial support (fast lane)
-
Wait for fund to afford a small contract (slow lane)
Deprecation effort update- GeoTools ready, green: https://github.com/geotools/geotools/pull/2309
-
Idea: QA page mention how to deal with deprecations
-
JTS update? Jody did not get back to that …
-
GeoWebCache ready, green: https://github.com/GeoWebCache/geowebcache/pull/747
-
GeoServer still needs java 11 deprecation handling: https://github.com/geoserver/geoserver/pull/3449
-
Use suppress warning if you cannot dodge (example implementing a deprecated method)
-
@SuppressWarning(“deprecation”)
-
Java 8 fix? new Integer(int) → Integer.valueOf( int )
Issues found in deprecation:
-
Deprecated methods/objects with no comment and no replacement
-
Deprecations in impl classes but the interface mandates the method without deprecating it
-
Deprecations pointing to replacement that are also deprecated and with no replacement
-
" * @deprecated Replacement to be determined."
-
Deprecating API, providing replacement, and leaving hundreds of calling points in the codebase, losing the best occasion to check if the deprecation and replacement actually make sense.
-
Deprecated with replacement indications making no sense. Remember to be clear, deprecation is not a reminder to yourself but something affecting users which need to move to a non deprecated approach.
-
Deprecated because normally it should not be used, but there are some legit cases to do so… just add a comment for it instead of deprecating
-
Deprecating a method because maybe in the future you will remove it (there were such deprecations 10+ years old, face it, you’re not clarvoyant)
GeoTools Care and Feeding
Dependency updates:
-
JTS upgrade was left out of 1.15.0, wait for deprecation PRs
-
Units library upgrade from email, for master only …
-
ImageN may be ready this release cycle …
Process API stable?:
-
Core API is map based (input and result maps, process descriptors) and is quite stable
-
RenderingTransform API interface describes “invertability” that is not captured in the process descriptors
-
Discussion of using a bean (with annotating attributes rather than annoting a function)
-
Approach is fine, we can make a factory for that, but does not change the core Process API