So to continue .. I would be content to relax the tests so that the
whitespace differences between Java 8 and Java 9 pretty printing do not
result in failure. The XML machine to machine functionality is not impacted.
--
Jody Garnett
On 12 January 2018 at 16: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
