Justin Deoliveira wrote: >>> By "forcing" clients to use the new model underneath the old we will >>> have the same issues, but they will be flushed out up front. Not >>> pushed off to the side for now and forgotten until later. >> This is where I have a conflict with you on scope; I expect clients >> to use the new interfaces (this means GeoServer and uDig) and no >> longer import org.geotools.feature.Feature. We tried to "stagger" >> this sort of change with the Filter API for GeoTools 2.3 and it did >> not work. >> > How did it "not work"? GeoServer successfully made the transition > gradually, which was the whole point of keeping the old interfaces > around, just deprecating them. GeoServer did in fact make the transition gradually; but this arrangement did not work for GeoTools - we are left with a release of GeoTools 2.3 in which users complain every week about Filter not working (when they use the GeoAPI interfaces *only*). I understand Andrea has back ported some patches at this time? Preventing a repeat performance is one of the benifits I hope for from "trunk on trunk". > And how do you expect clients to just switch without a cycle of > deprecation first? Last time I checked Feature has not been deprecated. Well I was working on the "switch to GeoAPI interfaces as they are made available" idea; I am fine with client code dragging its heels - but not fine with GeoServer and uDig dragging their heels. GeoTools can move as slow as these two applications.
Jody ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
