Ah, most of them are from the people cc'ed on this message, and for the bunch of functions generated by the dblasby's spike project named FunctionFilterWriter, I guess the best thing to do would be to modify the code generation class in order to use the same strategy mentioned before?
And for the wild, since those are automatically generated classes, does anyone feels we should have a maven plugin to generate them at build time while removing them from the code base? Gabriel On Thursday 23 November 2006 22:27, Gabriel Roldán wrote: > Hi all, > > as you may see in http://jira.codehaus.org/browse/GEOT-1038, almost all > FunctionExpression implementations in trunk are broken. > > I'm working on fixing it, but since it means modifying like 130 classes, I > want to ask the responsibles for direction: should I fix and commit, > provided that the test cases I wrote, which exposes 373 bugs, all pass; or > should I send a patch? > > btw, since most Functions inherit from FunctionExpressionImpl, the fix for > them is just to remove its internal Expression[] fields and properly > delegate to the superclass methods, which already take care of making the > deprecated methods play nice with the new ones from the GeoAPI Function > interface. > > Regards, -- Gabriel Roldán ([EMAIL PROTECTED]) Axios Engineering (http://www.axios.es) Tel. +34 944 41 63 84 Fax. +34 944 41 64 90 ------------------------------------------------------------------------- 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
