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

Reply via email to