Gah! Well, it's fairly critical mostly because I've got a *lot* of SLD sitting around that uses != filters. And, I suppose, because this is a non-trivial problem with the 1.5.x branch. I mean, if geoserver 1.5.x is ever to be released while based on 2.3.x, then this problem will need to be fixed at some point.
I poked a bit at changing the geotools FilterFactory to generate a Not(PropertyIsEqualTo) for a != filterType, but that's not going anywhere because "Not" isn't a CompareFilter...nor should it be. I guess I could cook up an isNotEqualToImpl that got around this, but somehow I think it would be pretty ugly. On the other hand, it's not your job to bail me out of switching prematurely to a developers version of Geoserver..this is what I get! Instead of having you rollback all those changes, make the fix, do the tag and then re-apply all the changes, how about this (I'll call it suggestion 1): * Sync your local copy to the date you made the 2.1-M1 cut * Create a branch from that point, calling the branch "2.1-M1" * Apply the patch to that branch and re-release 2.1-M1. * Send the "ping of death" to anyone that tries to develop anything against that orphan branch, directing them to send their efforts to trunk. Worst case scenario, we can use the 2.1-M1 branch for critical-path fixes supporting 2.3.x. That way you don't have to rollback and re-apply all those changes and yet we still get a working 2.3.x branch. Would that be less work? The alternative (I'll call it suggestion 2) is that if you can just give me the date you cut 2.1-M1, I can work out a fix and just make my own "non-standard" 2.1-M1 jar, even posting it if you want. That way you don't have to do any work because someone else screwed up! thanks, --saul Justin Deoliveira wrote: > Hi Saul, > > Yes, you are correct, and this interface was indeed just recently added > to geoapi. Unfortunately the fix requires a change to geoapi > FilterVisitor. Which brings us to another issue. > > Geootols 2.3.x seems to build against geoapi 2.1-M1 which from what I > can tell has no tag in the geoapi repository. I am to blame for this, I > must have forgotten to do this when i made the geoapi release. > > Unfortunately there have been some recent geoapi changes which would > break geotools 2.3.x, so moving 2.3.x to geoapi trunk isn't really an > option. > > So... to make a long story short here is what we have two options. > > Option 1: Create a geoapi 2.1-M1 tag, and roll back the recent changes > from trunk, then apply the patch to fix the PropertyIsNotEqualTo. > > Option 2: Fix on geoapi trunk and geotools trunk and wait for 2.4 to > pick up the fix. > > If this is a crucial fix for you Saul I can make some time this week to > apply the fix via option 1. Regardless i have thrown together a jira bug > for it. > > http://jira.codehaus.org/browse/GEOT-1021 > > -Justin > ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
