On Fri, Jan 12, 2018 at 2:13 PM, Jody Garnett <jody.garn...@gmail.com>
wrote:
> 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.
>
>
Looks like that issue is still open: GEOS-7375
<https://osgeo-org.atlassian.net/browse/GEOS-7375>, involved a
whitespace-only CDATA (space rather than newline, although I would assume
newline would give similar issues) and seems to occur when parsing a style
(SLDParser) - the Java 9 changes seem to be primarily involved with
encoding (SLDTransformer). That said, I wonder if the Java 9 changes might
make it easier to fix this one?
Incidentally, I just tried adding a newline test to SLDTransformer and it
worked fine.
Torben
> --
> 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