Jody Garnett a écrit : > Quick question; so I can understand ... how did you plan to use JaxB? > Near as I can tell you would need jaxb binding for Filter, Expression > and GML3? Will you be using the GeoAPI Geometry classes for the GML3 > binding; or morphing down to JTS Geometry objects.
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). > The plug-in system does offer you enough isolation that you can have a > set of style objects with jaxb annotations; my recommendation would be > to just use them as data transfer objects; and then use a style visitor > on the result to produce geotools style objects. I think Martin > performed similar tricks to allow any metadata interface to be "copied" > into the metadata implementation classes for persistence? 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: * 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 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. 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. Martin ------------------------------------------------------------------------- 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