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.
-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 > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------- 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
