This may be a good time to update our XML tests to use XMLUnit (
http://www.xmlunit.org/) instead of simple string comparisons to avoid this
sort of style issue.
Ian
On 13 January 2018 at 11:03, Ian Turton <ijtur...@gmail.com> wrote:
> I did some work to tidy up CDATA handling in https://github.com/
> geotools/geotools/pull/1735 which could have helped there. So it may be
> possible to close that issue off too.
>
>
> Ian
>
> On 13 January 2018 at 00:07, Torben Barsballe <tbarsba...@boundlessgeo.com
> > wrote:
>
>>
>>
>> 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
>>
>>
>
>
> --
> Ian Turton
>
--
Ian Turton
------------------------------------------------------------------------------
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