Hi Martin; apparently we needed you for this discussion - thanks for the detailed email.
Martin Desruisseaux wrote: > I may bring nothing new (the last Adrian's email explain well most of > my views), but I would like to summarize what I think are the most > important points: > > * We are not replacing existing technology. We are enabling a > functionality bundled in Java 6. This is equivalent to "implements > java.io.Serializable" to existing classes. Not quite; you are binding the java bean to one schema; ie Filter is written in Filter 1.1 format right? For Serialization you could provide a way for a modified class unmarshall data that had been written out using a previous version. Can someone tell me how this is done with JaxB (I just have not looked at the library enough; there should be a way right?). Can we do anything smart with XmlJavaTypeAdapter? or XmlAdapter? > * Enabling JAXB in Java 6 does not introduce any new dependencies and > have absolutly no impact on public API. It does not even appears in > the javadoc - it is really invisible. Understood. > * While it work well with Maven and NetBeans, Justin and Jody have > reported problems with Eclipse. I think this is just a technical problem; Eclipse is often very careful - I am sure we can fix this with a dummy jar or a solid jaxb dependency either way would work. Can we leave this one out of the debate - it is a build issue and does not matter in terms of long term planning. > * Justin worries about the philosophical implication of forcing a > technology. I also worry about this but I phrased it the other way; can we clean up the other technologies (SAX and DOM). Aside: Please note that these technologies also had the "single version" issue - so even though I keep mentioning Filter 1.0 and Filter 1.1 as an example - we may as a group decide we are okay targeting one version as a limitation. It is just that a limitation - as long as it is one we can accept we should be good. > * Why enabling JAXB and not Hibernate? Because JAXB is bundled in > Java 6 and used by other Sun technologies around Glassfish, while > Hibernate annotations would introduce a new dependency. Hibernate can now be used just from standard java persistence annotations; there are several persistance libraries that can read in EJB annotations and configure their "mapping" to relational tables. > * Adding JAXB annotations do not prevent you in any way to add > Hibernate annotations if you wish. True. > Annotations from different packages can live together no matter their > name. So we are not blocking usage of any other technology. We are blocking one specific use; we are blocking people from adding JAXB annotations (ie we already added them so they are stuck if they want to write a Filter out as part of Catalog Query and a WFS Query in the same program using JAXB. > * Simone worries about the confusion that could brings the mix of JAXB > and Hibernate annotations in the same class. Avoiding messy code is a > strong goal for me. But in this case, I see > this issue in the same way than a big method: when a method is big, > we use comments for separating logical blocks in the code. I agree that is is a concern; but I do find annotations to be more clean then the earlier attempts with magic javadoc comments used by Jaxor etc... we were doomed with lots of annotations the moment C# came out with the feature. > * Except for the problems in Java 5 build (to be resolved by removing > annotations from that build), the only real inconvenient I can see is > the increase in size. We can also do a trade off clean up the internal JDOM use and replace it with JAXB? > I want to setup an ecosystem with different flavors of GeoTools > releases: "Java 5 vs Java 6", "full featured vs lightweight", "all > referencing in one JAR", etc. May sound scary, but my understanding is > that distributed versioning systems is opening opportunities that we > didn't had before. We need to take on this challange; I was asked about it in my training course today by a customer; we have Thuens asking about it in South Africa. Can anyone in the community get a time/funding write down how to do distributed version control for GeoTools; and we should probably cover the use of an m2 repository mirror as well. 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
