That is great news Torben, some caution/testing is required when making
whitespace changes around CDATA sections.
A couple of developers (Alex and David) went in here to try and untangle
how whitespace either side of a CDATA section was getting "lost" when round
tripping from SLD --> (geotools style objects) --> SLD as occurs when
uploading an SLD to GeoServer via the REST API.
The tests all did SLD --> (geotools style objects) --> SLD --> (geotools
style objects) and found before/after differences, especially when the
CDATA section itself was a newline.
--
Jody Garnett
On 12 January 2018 at 13:59, Torben Barsballe <tbarsba...@boundlessgeo.com>
wrote:
> I took a deeper look at the SLDTransformer failures. As noted in the PMC
> Meeting notes thread, the failures are related changes in XML output,
> particularly surrounding pretty-print / indentation.
> Looking at the test cases, the Java 9 result actually seems better than
> the Java 8 result. For example:
>
> Java 8
>
> <sld:Label><![CDATA[abc ]]>
> <ogc:PropertyName>myProperty</ogc:PropertyName><![CDATA[
> def]]></sld:Label>
>
> Java 9
>
> <sld:Label>
> <![CDATA[abc ]]>
> <ogc:PropertyName>myProperty</ogc:PropertyName>
> <![CDATA[ def]]>
> </sld:Label>
>
> Both results still represent equivalent XML - CDATA and such is preserved.
> Java 9 just handles indentation around text, labels, and CDATA more
> consistently.
> So, if non-functional differenced in SLD output are okay, then we can just
> update the test cases (I've currently got some viable test cases locally).
>
> However, if we want exactly identical functionality, that will be rather
> more difficult. The indentation handling is pretty deep in the XML encoder,
> and indentation is really only controllable for a the document as a whole.
> Any workaround would likely be hacky, or involve a different XML framework.
>
> Thoughts?
>
>
> Also, in the interests of exposing as many current failures at once, I've
> added -fae (fail at end) to the maven job. (Doesn't help much right now
> since we are failing on main, but once that passes should be helpful)
>
> Torben
>
>
>
>
> On Thu, Jan 4, 2018 at 2:28 PM, Torben Barsballe <
> tbarsba...@boundlessgeo.com> wrote:
>
>> I've updated the epsg-wkt tests with a threshold, and they now work with
>> both Java 8 and Java 9 (locally at least). This definitely seems like an
>> issue to be aware of (and something that should probably be mentioned in
>> any initial blog post discussing GeoTools Java 9 support), but I don't
>> think it is going to cause any immediate issues?
>>
>> Fix for the tests here: https://github.com/geotools/geotools/pull/1783
>>
>> Torben
>>
>>
>> On Wed, Jan 3, 2018 at 2:31 PM, Vincent Privat <vincent.pri...@gmail.com>
>> wrote:
>>
>>> Hi Torben,
>>> Thank you for testing Java 9.
>>> We faced similar reprojection issues in JOSM unit tests two years ago.
>>> You can find valuable information (why it happens and how we solved the
>>> issues) in our bugtracker:
>>> https://josm.openstreetmap.de/ticket/11889
>>> https://josm.openstreetmap.de/ticket/13387
>>> https://josm.openstreetmap.de/ticket/11924#comment:91
>>>
>>> In short: Intel submitted a new native Math library in Java 9. It is
>>> faster and more precise, but not backward compatible with numeric results
>>> produced with Java 8 and older versions so you have to allow some
>>> difference. We also backported Java 9 Math.toDegrees/toRadians
>>> implementations
>>> into our code base to benefit from their accuracy and performance.
>>>
>>> Cheers,
>>> Vincent
>>>
>>> 2018-01-03 22:51 GMT+01:00 Torben Barsballe <tbarsba...@boundlessgeo.com
>>> >:
>>>
>>>> I have set up a Java 9 build on build.geoserver.org: https://b
>>>> uild.geoserver.org/view/geotools/job/geotools-java9
>>>> (also set up builds for geowebcache and geoserver, but those aren't
>>>> likely to be relevant until geotools builds on java 9)
>>>>
>>>> The build is set up on a shared workspace
>>>> "/var/jenkins/workspace/java9", with an isolated local data dir (using
>>>> -Dmaven.repo.local) so that the downstream builds can use upstream
>>>> artifacts without contaminating other builds.
>>>>
>>>> So far, the build seems to be running as intended, but is currently
>>>> failing tests on gt-epsg-wkt.
>>>>
>>>> Seems like envelopes are sufficiently different upon reprojection to
>>>> show as unequal.
>>>> A similar issue (also with Java 9) has already been reported here:
>>>> https://osgeo-org.atlassian.net/browse/GEOT-5899
>>>>
>>>> Torben
>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> GeoTools-Devel mailing list
>>>> GeoTools-Devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>
>>>>
>>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
