Vincent Heurteaux ha scritto: > De-facto standards are always good because they reflect what users > really need, I'm ok with you on that point. But what concern's me is > thas usually de-facto standards have been developed to achieve a > particular goal and after, they've been adopted by the majority for it's > needs.
Or maybe not. Let me tell you a little anedoct. When JPA came out, at my old working place, we looked into switching to the new shiny standard instead of being tied to Hibernate, that is, use standard annotations instead of the xml files we had. All seemed to work fine until... we discovered the specification left out a critical feature that we used in most collections, "cascade-delete-orphan". Looking into the net it seems that will be part of JEE6. And we were already using that 4 years ago. Now, there are some workarounds, like: http://chstath.blogspot.com/2007/04/where-is-delete-orphans.html but that is certainly a pain to code with, and since we had 50+ of those collections and a complex system to use them, retrofitting our system was not an option. So I'd say, at least for this case, the de facto standard was ahead of the spec, and still is... A similar situation appeared when we faced the problem of choosing a web UI framework for GeoServer. JSF is component based, well described in book, supported by tools... what's not to like? Well, it does not support the development of a pluggable UI, you have to create that as a monolith. Wicket does that today instead. Struts2 too. Maybe one day the standard will incorporate this feature too, but for the moment, we're going another way. I did not ditch JSF because it was from Sun, but because I could not get it to work. So see, my preference to real world implementation vs official standard is based on experience of what I could not do with the official one. Now, back to the topic, JAXB with java5 is proving to be a pain for Eclipse users, but I believe it can be fixed so that we can work together by hammering some more the jaxb-dummy module. What's more painful is to have all this duplication around (gtxml vs jaxb, streaming renderer vs go renderer, ...) but it seems like the only way we can collaborate. We need more interfaces so keep everybody working on its implementations, eventually we may end up having two parallel set of modules doing similar stuff for most of the functionalities, but I'm not really seeing any good way out of this. Cheers Andrea ------------------------------------------------------------------------- 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
