Hi Saul,

I can create the 2.1-M1 branch in geoapi and apply the patch which will
fix the problem. There aren't many active geotools developers with
geoapi access ( i believe myself, jody, cory, and martin ), so if we can
call agree that we will create the branch only for this emergency fix,
then that should work fine. And since 2.3.x is going stable there
shouldn't be a need for any more geoapi development for it.

-Justin

Saul Farber wrote:
> 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
> 
> !DSPAM:1004,455a1c1e96852207481331!
> 


-- 
Justin Deoliveira
[EMAIL PROTECTED]
The Open Planning Project
http://topp.openplans.org

-------------------------------------------------------------------------
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

Reply via email to