The actual fix is https://github.com/openstreetmap/osmosis/pull/51
As can be seen this is a very long time bug (from 2007 with a fix available since 2007) with apache xerces (the XML parser) which osmosis has an explicit dependency on. However the version of xerces included in JDK since 2015 has the patch applied so the fix is simply to remove the explicit dependency which wasn't needed with modern JDKs in any case. Simon Am 12.04.2019 um 11:03 schrieb Simon Poole: > https://github.com/openstreetmap/osmosis/pull/50 > > Am 12.04.2019 um 10:16 schrieb Maarten Deen: >> On 2019-04-12 09:52, Simon Poole wrote: >>> Am 12.04.2019 um 08:26 schrieb Maarten Deen: >>>> Does the determination in java follow the same rules (or even the same >>>> library) as file(1)? In its manpage it says >>>>> file tests each argument in an attempt to classify it. There are >>>>> three sets of tests, performed in this order: filesystem tests, magic >>>>> tests, and language tests. The first test that succeeds causes the >>>>> file type to be printed. >>>> Is there any similarity in the first bytes of the zipped file? >>>> >>> This would be a valid question except: I hardwired the decompression >>> type to GZip yesterday in a test version of osmosis and still got the >>> error and as said a test program using the same methods decompresses the >>> file just fine. >> That is interesting. I don't know how the unzipping is done in >> osmosis, but if it is still a java call (now hardwired to use gzip, I >> assume the executable, not a built in library), could it not be that >> java still tries to figure out what kind of file it is and fails >> because of that? >> >> Regards, >> Maarten > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk
signature.asc
Description: OpenPGP digital signature
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
