What a complicated problem! Thanks for the summary of options. As you have noted we need to make a Converter out of this functionality - so that both read/write in the XML parsers and the filter/expression implementations benifit. I would like to stop handing out documentation for the old GML2 parser/encoder - but until justins parser goes to supported status that is not an option.
My preference would be to: - ensure the GML2 parser/encoder to make uses of the Converter API - so we can isolate this fix to one locaiton - grab the code from jaxme and just plan to keep it (we could switch our converter to use jaxb when Java 6 is an option) To use the code you will need to stick a copy of the apache license into the module, and the header for the file will need to the file as coming from the jame project, the (c) date, and the license it was made available with ... although we say GeoTools is an LGPL project the review process shows that we have a mix. Cheers, Jody > Hi, > I'm writing this mail following a request to have date and time > properly both read and write wise in the geotools XML parsers. > > At the moment we have the following situation: > * old GML2 parser/encoder, it's able to encode date and times > properly, but does not take into account time zone. > Parsing is completely broken, we could use DateUtil for > the parsing but it would accept only a subset of the > acceptable date time expressions anyway (and disregard > again the timezone) > * new GML2 and GML3 parsers are ok both direction, but they > are using JAXB for it. To be more clear, they are adding > a 1MB+ dependency just to use the DatatypeConverter class > and its few dependency. > > I looked around and found out the jaxme project, and open > source implementation of the JAXB library under the Apache > license, and extracted a working DatatypeConverter which > you can download here (it's a standalone eclipse project > for the moment): http://geo.openplans.org/aaime/jaxme-converter.zip > > Now, it would be nice to use this one from the size point > of view, there are a few drawbacks thought: > * license. Can we mix this sources into the main module? > Or in its own standalone module? > * after extraction we are on our own, we don't get anymore > bugfixes just by upgrading to the lastest implementation. > > So, I would like to hear your opinion. What shall we do about this? The > alternatives I see are: > * say bye bye to the old GML2 module inside main, it's not fully > working, and keep the big dependency on the new modules > * create a new module with the attached file, handling > license issues, and change both to use this new converter > > I also heard that java6 has jaxb included, but this is > not a solution, since we're years away from adopting java6 > as the base. > I have just confirmed this - listed as a feature on this page: - http://java.sun.com/developer/technicalArticles/J2SE/Desktop/JavaSE6_build39.html ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
