Mauricio Pazos ha scritto:
> On Sunday 17 May 2009 22:05:17 Andrea Aime wrote:
>> I looked into jjtree-javacc usage. There are two
>> use cases for this module, the main module, and the
>> cql module.
>>
>> In the main module it's used by an old text expression
>> parser that is marked as deprecated (ExpressionBuilder).
>> I'd say, let's just remove it and in the few places
>> where it's used, let's just build filters by code
>> (cql cannot be used in main, that would cause a
>> circular dependency).
>>
>> In the cql module it's used and I don't see an
>> easy way to remove it. In particular, the parsing
>> design fights again the jjtree/javacc standard
>> practice and tries to replace the standard Node
>> interface with a custom made one (instead of
>> asking jjtree to extend a user provided base
>> class)
>> This is not supported by the Mojo version of the
>> jjtree plugin, and results in compile failures.
>> Mauricio, how hard would it be to fix this issue
>> in your opinion?
> I think the main problem is the circular dependency. The cql implementation
> is
> not the problem.
> In the in src/main/java we could remove
>
> org.geotools.filter
> ExpressionBuilder
>
> org.geotools.filter.function
> FunctionTestSupport (it is not used)
>
> Thus cql is only required by
>
> org.gotools.filter.visitor
> EnvironmentVariableResolver
>
> public Filter resolve(Filter filter, double mapScale) throws
> /*ParseException, */CQLException {
> String input = filter.toString();
> input = input.replaceAll("sld:MapScaleDenominator", ""+mapScale);
> // Filter output = (Filter)ExpressionBuilder.parse(input);
> Filter output = (Filter)CQL.toFilter(input);
> return output;
> }
> public Filter resolve(Filter filter, double mapScale) throws
> /*ParseException, */CQLException {
> String input = filter.toString();
> input = input.replaceAll("sld:MapScaleDenominator", ""+mapScale);
> // Filter output = (Filter)ExpressionBuilder.parse(input);
> Filter output = (Filter)CQL.toFilter(input);
> return output;
> }
>
> Is possible move EnvironmentVariableResolver to other module to avoid the
> circular dependency? (It look like an util class)
I think we can drop also the EnviromentVariableResolver, as it's quite
old and not used anywhere that I know of.
I tried to make the cql module build with the Mojo version of the javacc
plugin but failed. Imho this is the main problem standing on the road
of removing the custom geotools jjtree-javacc plugin.
This could be dealt with another way thought. If you feel like becoming
the maintainer of that plugin we can easily keep it around.
My suggestion to remove it was based on two points:
- it is not maintained by anyone
- an external project providers almost the same functionality
Unfortunately I could not manage to get cql building with the
Mojo javacc plugin (which I used with success in GeoServer btw),
that's why I wrote the mail above.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
