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