Justin Deoliveira ha scritto: > Hi Andrea, > > Aplause for your efforts. Perhaps drawling the line at modules in the > library and forgetting about plugins. Especially with the new jdbc > datastores about to emerge... just a thought.
Yeah... and no :) The thing is, for sure I'll work out first anything that I know is not going to be replaced anytime soon. Once that is done, I'll look around. If the old jdbc modules are not going to disappear overnight I'll be forced to fix them too. I want to avoid a domino effect that makes me do 10 big other things instead of finishing the cleanup, as that has a tendency to replicate into a never ending scope expansion. Cheers Andrea > -Justin > > Andrea Aime wrote: >> Hi, >> after a bit of discussion at FOSS4G I decided to take >> another peek at cleaning up GeoTools from the old >> filter interfaces, leaving only GeoApi ones around. >> >> I've tried to organise a sort of a long distance sprint >> one year ago, but that did not get any traction and was >> abandoned. >> I guess I learnt the lesson, this time I'll set up >> to do all the cleaning by myself (but if you want to >> join and help, please, you're most welcomed). >> >> The rough idea is relatively simple: >> 1) find and kill any usage point of the old GeoTools >> filter api. >> 2) remove the GeoTools interfaces from the filter >> implementations >> 3) move the GeoTools filters into the legacy module >> >> A very big amount of filter usage is in unit tests, >> I'm quite confident I can work alone there. >> Bigger concerns arise from modules where I'm not >> maintainer nor I got the get go for commits from >> the maintainer: >> - it usually means I'm not familiar with the module >> - I just cannot go and commit, so a maintainer >> unwilling to cooperate (in terms of reviewing >> my patches) will kill the effort at step 1) >> >> Some concern comes from the unmaintained modules, >> whilst there is no one stopping me from cleaning >> up the filters there, I also have no one to >> ask clarifications to. >> >> The old jdbc modules raise some concern as well, >> various of them still use SQLEncoder (which depends >> on the old geotools filters), not sure >> it is a good idea to try and switch them to >> FilterToSQL, the time is probably better spent >> switching the entire module to the new jdbc >> architecture instead. >> >> Finally, a word about the size of the effort. >> A very quick way to get a rough idea is to look >> for org.geotools.filter imports in java files, >> Eclipse reports around 1200 of such imports. >> The estimate is probably a little exaggerated, >> but gives an idea. >> And way is to look for references to the old >> Filter and FilterFactory classes, Eclipse reports >> the following: >> - org.geotools.filter.Filter: 788 references >> - org.geotools.filter.FilterFactory: 291 references >> >> Well, I guess that right now I'll start by switching >> the unit tests, it's boring work, but also a safe >> one. Hope to hear some feedback from the other >> developers, especially in terms of risks and issues >> that I failed to asses. >> >> I also created a wiki page to summarize the status >> the various modules in terms of filter usage and >> cleanup status: >> http://docs.codehaus.org/display/GEOTOOLS/GeoTools+filter+cleanup >> >> And oh, whatever I do filter wise, I'll do only >> on trunk, I'm not going to touch 2.5.x. >> >> Cheers >> Andrea >> > > -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
