Hi Martin; I am listening. Martin Desruisseaux wrote: > Okay, one last try to explain: > > * You objected that putting JAXB annotations would prevent usage of > other annotations like Hibernete > WRONG: Each annotations live in their own packages. Agreed; let us move on. > * You objected that putting JAXB annotations would prevent users to > extend those classes with their own annotations. There is just one small technical glitch here; we would prevent them placing JAXB annotations targeting a different (say applicatoin specific schema). We are in effect saying we like Filter 1.1 so much you cannot use this object in your own xml schema for your application.
This is not a bad thing; can we acknolodge it as a limitation (with a known workaround - ie implement your own data object and use geotool's ability to use a factory to continue working). Ie this is not a big deal; we designed to give people this kind of flexibility. My very first email on this topic; where I was honestly joking about JAXB because I did not seriously think anyone (including you) would be using it - my first response was to say "cool - you can do that using a factory". ie we planned for this kind of stuff? > * On "Why JAXB and not Hibernate", Andrea said that there is > standardized annotations that Hibernate recognizes. > If this is standard, then I'm all for declaring them. Are they > standard? I mean the annotations AND the > database schema. With JAXB annotations, the XML schema is standard: > ISO 19139. It is not a standard at an ISO level; it is a standard at the EJB3 level. We could (and should) mark up the metadata classes with EJB3 annotations; that is the major reason I had a customer fork the metadata module... The other thing we could do is set up a factory; so at the very least geotools does not get in there way when they want to use hibernate. Cool? > * You objected about the multiplicity of XML parsing methods. JAXB is > *invisible* in the API. They *enable* usage of those > metadata classes in SUN technologies. If you don't like SUN > technologies, nothing force you to use them. It is still a valid argument for the library development - any change that plans to use JAXB needs account for the legacy code (ie have a plan to clean it up); Can you help us clean up the SAX and DOM parsers - perhaps have them use JAXB behind the scenes? > * I offered many time to setup an system of different GeoTools > flavors (this is needed anyway), given users the choice between > metadata with and without JAXB. Why this is not suffisient for > cooling down this issue? Honestly it would not right now; the trick is how can we communicate a little better - just like I managed to annoy everyone by changing FeatureCollection without sufficient public review; geomatys has a similar "crises" in that technical direction is not being shared and you have managed to "surprise" us with new requirements when a deadline for Eclesia is measured in weeks :-) Poor Eclesia, Poor community .... and poor planning. So can we talk about getting some mid term planning (measured in months) out in the open so we don't have a shock like this? In the mean time please recognize that the community is in shock and you are going to have to put in some time sorting it out. If you have design docs to share that would help .... I wrote massive design docs before changing the referencing module. Please show us what you plan; we can help on the parts you are not sure of (like getting rid of the SAX and DOM parsers). Both Chris and Vincent were on the right track in terms of these planning concerns. If you can review their email you can see these concerned expressed in a polite way. As a project lead I am going to need to want talk to both organizations; we should not of let things get this crazy just in terms of risk management; as a PMC we should of been on top of this. Although I suppose our change procedure did bring this conversation out - so it is not a total loss. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
