Andrea Aime wrote: > Rob Atkinson ha scritto: > >> Warning - bear of little brain playing with the code base :-) >> > > ... > > Not quite sure what to make of that ... >> On a general note - I'd like to help test the docs for the migration >> path here, and the API implementations I guess, but need some more >> insights into the state of play. In particular I cant find any >> implementations of the new Filter/Expression stuff in any modules within >> gt2 trunk, so am relying totally on the code. >> >> Is this upgrade happening on a different branch, or on someone's machine >> and not yet committed perhaps? >> > > I would like to know me too. On a separate note, I would like to point > out that 2.3.0 provides Geoapi filters as the non deprecated way of > doing things, too bad they do not work at all if you use them (tried > to port back the IsEqualsImpl tests, had to rewrite them against the > old Filter API). > > I guess that would be another point in trunk mantainance policies. Want > to do a API shift? Make the new one work before deprecating the old one, > and make the new one avaialable only when you're ready to deprecate the > old one. That is, when I do use something, I would be happy to know that > it's there because it works. > A message like "this is deprecated, but no, don't use the new one > because it does not work" is really not a good one. Not happy... :-( > > OK - its not just me struggling with this then. On the other hand, I'm motivated to try to test the new API out. Justin is working on a SQL encoder for postgis - how does this relate to the generic JDBC stuff - can we fix this first so we can update other data stores and get more testing, or are we going to end up dumping the common base and having many cloned versions of the implementation to manage? Can we extend a new version of JDBC for example? I know some discussions happened broefly - is there a definitive statement anywhere of what is being done?
The inability to get Geoserver near trunk is obviously a cause of API changes not being tested. If we could propagate the non-deprecated methods all the way through the implementation chain I'm sure they would be more likely to be made to work. Unit tests are fine, but they arent good motivations to actually make things work in the first place. > Cheers > Andrea > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
