Martin Desruisseaux wrote: > Jody, in the above quoting you omitted the Andrea's words I was replying > to... > Up to this point, all my emails were only technical. You can verify in the > archives. > No I did Martin; and thanks for taking the discussion technical again. Changing the subject line was actually me changing the subject - I wanted to make sure I was communicating where frustration was occuring so we could figure out ways to address: - the design tension - it is a fascinating problem - the community tension - it is also a fascinating problem > Anyway... as you said well the issue became emotional. The frustration was > reciprocal for different reasons. But I would like to stretch out again that > we > are not trying to push for JAXB annotations on trunk if peoples don't want > it. > This is understood; also understand I am not against the careful integration of JAXB onto trunk (say for GeoTools 3 :-) ). I would like make to sure we tell a consistent story; ie "we are making jaxb bindings available" and the SAX / DOM users can make use of it via the the following methods ... ie we need a goal (you got one) a reason (you got several) and a migration stratagy (we need one to make the idea variable) > Again to repeat what I'm saying since many emails: we tried on GeoTools trunk > with Java 5, I'm fine to call the experiment a failure if peoples wish I am sure we can make it work; there is a new version of Eclipse out yesterday; perhaps it has fixed this problem? Or perhaps it is a real problem ... eclipse often finds real problems the Java compiler does not. > and I proposed to create mercurial clones for JAXB and remove the annotations > from SVN trunk. > That is a good idea; and something we need to explore (and document) because there is real need. >> It feels like geomatys is doing an end run around working with us when >> changes pop up in GeoAPI (even in GeoAPI it feels bad when interfaces >> appear before implementations; it is not something I want to see done to >> GeoAPI). >> > A while ago, GeoAPI had a "pending" directory for this kind of work. This > directory has been replaced by "trunk" for better alignment with common > practice. If there is an other layout proposal, I'm open to that. The layout > may be to put experimental interfaces on GeoTools SVN - I'm fine with that > too. > I agree about use of trunk it is more clear all around. I am more worried about the "two implementations" rule that I would like to see used for GeoAPI interfaces. Is that something we can get done - or at least take steps to get done? Alternative ideas: - I would even settle for an implementation first idea - ie to keep geoapi grounded in reality - test cases showing sample use - even if they cannot be run?
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
