> For now, it's clear we've to deal with the different approach that > each project has taken, and two solutions are facing us : > 1) finding a non-blocking solution that satisfy everybody (it seem's > annotations could let us enough room for that This one is hard - because the problem is hard; I really respect that JAXB is a viable / marketable concern; I also respect Justin in that it does not have the mind share of easier solutions like XStream.
In GeoTools 3 where everything is beautiful; - The GTXSD xml technology is untangled a bit more from EMF (writing bindings is not that hard; and may be easier than using EMF). - We include XML schemas we care about with the library; hacked up to be valid if need be. The library knows what the different schemas are and the information is available for programmers to refer to. - We provide JAXB support for glassfish etc making use of code generation on a "representative schema"; allowing different versions to be tracked - we drop SAX support - asking it to call GTXSD as needed - we drop DOM support - asking it to call GTXSD as needed - we drop the various Transformers asking it to call GTXSD as needed - Andrea makes GTXSD fast by removing the slow parts References: - https://jaxb.dev.java.net/guide/Mapping_interfaces.html - http://forums.java.net/jive/thread.jspa?threadID=25980&tstart=60 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
