For completeness, we actually have a few more JSON libraries in GeoTools/GeoServer in addition to what you listed:
- Google GSON for MongoDB and ArcGIS REST (in GeoTools) and for WMS TopoJSON format and the GeoGig community module (in GeoServer), which is active. - Jettison 1.0.1 (via XStream) for the JSON portion of the REST API (Only in GeoServer). While the project is active, we're stuck on a 10-year old version for backwards compatibility reasons. GSON is primarily intended for transforming Java to and from JSON , but it does have minimal JsonPath <https://google.github.io/gson/apidocs/com/google/gson/stream/JsonReader.html#getPath--> support (With more robust integration added by the Jayway implementation that you already mentioned). There's also a seemingly abandoned fork <https://github.com/johnnylambada/gson/commit/344bd2fd4911146e761926d5ee1b441ba6bb9cfa> that adds Json-Pointer support. Overall, it seems like GSON doesn't quite have the capabilities you are looking for, but it is already a dependency of some GeoTools modules so maybe consider it? More generally, I'd definitely say go for a JSON library we already depend upon (given that we have too many already), be it Jackson or something else. I think it's reasonable to add Jackson to gt-main. Having a JSON library as part of a core module might encourage others to use it rather than adding their own (although I rather doubt it). Torben On Wed, Jan 23, 2019 at 8:24 AM Ian Turton <ijtur...@gmail.com> wrote: > I'd say go for Jackson as a main dependency and then someone (or me) could > try to bring the other JSON modules uptodate by using it, I might even > merge the two at the same time, but not until the weekend :-) > > Ian > > On Wed, 23 Jan 2019 at 15:45, Andrea Aime <andrea.a...@geo-solutions.it> > wrote: > >> Hi all, >> as you probably know GeoTools is now sometimes carrying around JSON in >> feature attributes >> (e.g., see JSON support in PostGIS data store). >> The JSON is represented as a String. >> >> Now, I'd like to add a filter function to parse and extract specific >> properties out of the JSON string... which >> requires new dependencies. And boy we have a mess of them in the >> classpath already: >> >> - json-simple, used in geojson and mbstyles, but dead, last release >> is 2012 >> - json-lib, used in GeoServer for geojson generation, and also dead, >> last release is 2010 >> - jackson, used by Spring and directly by some GeoServer community >> modules, with recent releases and latest commits of only a few days ago >> >> >> There are basically two languages to extract stuff from JSON, json-path >> and json-pointer. >> json-path is the one I would have preferred as it's more powerful, but >> its situation library wise is not >> exactly in great shape, the jayway implementation uses yet another json >> java library, json-smart2, also dead. >> There are a couple of other options for json-path, either dead or with a >> bizzarre "do not evil" licence. >> >> json-pointer is instead supported directly by jackson-core, which is well >> alive, and comes with a 300kb jar >> that has no external dependencies. This seems the best bet, just one >> hesitation... should I add a jackson-core >> to gt-main? On one side, it seems a large-ish dependency for just a >> function, on the other side having a single >> class new module also seems a bit overkill. >> >> Opinions? >> >> Cheers >> Andrea >> >> == GeoServer Professional Services from the experts! Visit >> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf >> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa >> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 >> http://www.geo-solutions.it http://twitter.com/geosolutions_it >> ------------------------------------------------------- *Con riferimento >> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - >> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni >> circostanza inerente alla presente email (il suo contenuto, gli eventuali >> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i >> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per >> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le >> sarei comunque grato se potesse darmene notizia. This email is intended >> only for the person or entity to which it is addressed and may contain >> information that is privileged, confidential or otherwise protected from >> disclosure. We remind that - as provided by European Regulation 2016/679 >> “GDPR” - copying, dissemination or use of this e-mail or the information >> herein by anyone other than the intended recipient is prohibited. If you >> have received this email by mistake, please notify us immediately by >> telephone or e-mail.* >> _______________________________________________ >> GeoTools-Devel mailing list >> GeoTools-Devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > > -- > Ian Turton > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel >
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
