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 adding
"implements java.io.Serializable" to existing classes.
* 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.
* While it work well with Maven and NetBeans, Justin and Jody have
reported problems with Eclipse. I'm ready to accept as a failure
the attempt to make JAXB invisible to the Java 5 build. So we are
looking for way to remove JAXB annotations from SVN trunk and keep
them on a Java 6 "branch" (I said "branch" but I'm actually thinking
to something along the line of "Mercurial repository clone" - it
still need to be investigated).
* Justin worries about the philosophical implication of forcing a
technology. I disagree: we are not forcing it, we are enabling
it. To make a comparaison with Java I/O, declaring a class as
Serializable does not force anyone to use Java serialization
mechanism. Again I repeat: it is totally invisible in the API,
so it even does not put any conceptual weight on user side.
* 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.
* Adding JAXB annotations do not prevent you in any way to add
Hibernate annotations if you wish. Annotations from different
packages can live together no matter their name. So we are
not blocking usage of any other technology.
* 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. Same applies to annotations: "// JAXB annotations", the
annotations, "// Hibernate annotations" (or whatever comment
introduce a clear visual separation), the Hibernate annotations.
We can avoid messy code if we comment it well.
* 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. But if size was a major issue, we should
already be using PACK200. Nevertheless I understand that the GeoTools
project is big and I don't think that "one size fit all". So to repeat
myself again: 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.
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
