I am getting a lot of email on and off list about the range of XML "solutions" in the geotools library. We do need to bet on a horse and stick with it. I do understand that JaxB being folded into Java is an attractive target.
But martin I thought JaxB was not up to all the uses we have for XML? There is a seperate Java project on JaxB bindings for all the OGC stack; I ignored it at the time but perhaps you would be interested? > We would need bindings for them too. Our next target is referencing. Right > now > we are stopped because JAXB can't parse immutable objects. But this is a > known > issue, so we hope that it will get fixed (if not, we have workaround). It is > a > good thing to be stopped since it give us time to consolidate what we tried > in > metadata (consolidation may include removing JAXB from trunk and move them in > some branch instead). > Agreed; I am very interested in your JaxB experience - I am glad the introduction of factories can help keep the JaxB decision away from being forced on users of the library. > I used some trick using reflection, true. It would have been possible to use > JAXB classes only as data-transfert classes, but the capability to annotate > directly our "real" classes is precisely one of great JAXB attractions to me: > My question is how do we annotate the same class for two different XML serializations? > * allow developper to keep XML mapping close to code (like javadoc) > * avoid duplicating real classes with data-transfert classes > * remove a step (copy from real class to data-transfert class) during > parsing/formatting, which have both performance and memory implication. > > However I realize that it can be a cause of troubles for Java 5 users. I am sure we can solve them; JaxB is just a library and it is available to Java 5 users. At least I hope we can solve it ... > I also realize that it make JAR files bigger than needed for those who don't > want to > use JAXB. It may be difficult to find a "one size fit all" flavor. This is > why > I'm tempted to explore some way to build different flavors of GeoTools: with > or > without JAXB, Java 5 or Java 6, full or trimmed referencing module, etc. Yeah we need to carve out a couple distributions of geotools for specific audiences it is true. > I wonder if distributed versionning systems may help us to keep synchronized > a > single trunk and a few flavors. I'm not sure yet that it is doable, but I > have > the feeling that it may be. > I am sure it is doable; and I am also sure we have to do this (if only for our developers in South Africa and Australia). I just want to be very careful that we are not setting ourselves up for a series of "walled gardens". As PMC it would then end up being our task to round up fixes from the different repositories etc... and our PMC is having plenty of fun just attending meetings and trying to get change proposals to include documentation. I think of the last 5 change propsoals only a couple managed to write user docs (perhaps we could ask docs to be written before the code?). Cheers, Jody ------------------------------------------------------------------------- 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
