Andrea Aime wrote: > Rob Atkinson ha scritto: > >> 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 ... >> > > Sorry, I usually remove the non relevant part of a message in a > reply to keep replies short, and put ... in the place I did remove. > Thought it was a common convention? > > Was merely amused that you thought that bit highly relevant :-) >>>> On a general note - I'd like to help test the docs for the migration >>>> > > --- 8< snip snip 8< ------(does this look better for removed content?) > > >> 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. >> > > Agreed, I don't like half backed changes me neither... yet this raises > a concern. Who is in charge for the changes? Asking a single person to > do that would mean he has to understand more or less the whole code > base. Putting the burden on each module mantainer is a secure recipe > for not getting things done I fear, thought. Maybe adding a blocker > issue on the modules to update to the new API could be a way? (and who's > gonna open 50 issues against all modules?) > I reckon we get the JDBCmodule updated ( or a replacement) then try to get some key modules updated. By the sund of it we need to leave deprecated methods at least one more cycle, and our priortiy has to be to propagate through key datastores and geoserver and uDig code bases. Then module maintainers have a "I dont want my module to fall off next release" motivation, but it cant happen without a few working.
Is Geoserver OWS4 working against new APIs? > 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
