Martin Desruisseaux wrote: > Jody Garnett a écrit : > >> 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. >> > But if the metadata classes were not annotated at all, it would not make much > difference for the users. Good point; can they subclass and annotate the subclass different? Is that an approach we can use when migrating from Filter 1.0 to Filter 1.1? Any other ideas ... > no matter if the classes are annotated or not, the user needs to modify the > source code if he wants his own annotations. Or do I'm missing something? > I saw a couple things when I did research: - It looked like you could make a modified schema that hand <jaxb:annotation> elements in it to generate a parser for an existing set of java beans. - There was some indication you could use a special jaxb adapter annotation and punt out to some java code to make the decisions
Finally the major point is the standard annotations between java beans and some entires in an xml schema; that is what the binding framework needs. I wonder if we could use this annotation metadata to bootstrap our GTXML parser. I would even be a good idea (does not handle the multi-schema problem but does offer the benifits of a dynamic parser). > Sure being limited a single version is a limitation compared to gtxml. But > again I'm not pushing for a replacement of gtxml. This is about enabling (not > forcing) a serialization mechanism. > I understand; and you have said this in several emails now (perhaps I am answering the email in reverse order?). I think we are on the same page: - you are not trying to remove GTXML - I am trying to remove SAX, DOM and XDO - I want a want a larger picture goal / migration plan / discussion of the consequences of using JAXB in our shared future >> 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). >> > Seing JAXB being a cause of a shock was surprising. The reaction seems out of > proportion compared to the implication. The objections were: it would prevent > other annotations like Hibernate, introduce more dependencies, force the > usage > of a particular technology, etc. We could debate if those objections were > true. > But since they are not accurate, effectiveley if leave room for more > emotional > than rational debates. > No the shock was on the communication front - as you mentioned the technical details are not that important. The shock was was the decision made in isolation; a decisions that can not be used library wide (not much of a problem but something we need to figure out); and lack of a migration plan / consistent product story for geotools as a library etc... As an example where this went well: the style interfaces - I need the FunctionName thing resolved for this API to tell a consistent story (and it was in my very first review months ago). It was not a shock when the idea came up in my review this week. Oh and this long term planning stuff is something we should be doing as PMC members - it is what our role is. A company like Geomatys should not be forced to figure out all this stuff on their own. Having a vision is why you have a open source project; discussions like this are how we nail down a shared vision. The counter is that working with the community is a risk - the proposal process has helped a lot on that. The example: When Eclesia presented the style interfaces changes what he was about was nice and clear and Andrea and myself were able to give him timely feedback in an organized fashion. Jody 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
