Going back to the top of the thread, taking it from a purely technical
aspect.
The CSS module actually incurs a lot of complexity trying to translate the
CSS cascading properties model into SLD (where the painter's model reigns.)
There's some complicated filter analysis stuff going on [1] and some fancy
graph stuff to avoid enumerating all possible combinations of CSS rules
[2]. As functional techniques generally shine for algorithmic code I would
expect these to be more problematic to convert to Java than the parser
itself. However, it might be interesting to think about modifying the
renderer in GeoTools to be able to work with CSS styles directly and avoid
requiring this conversion in the first place. Actually from speaking with
the Carto guys it sounds like they found a middle ground that made style
conversion simpler without requiring a ton of changes to the renderer by
adding an option to switch to "first match" instead of "all match" mode.
On the topic of parsing, I expect that a pre-made CSS parser will be
insufficient as I am pretty sure that embedded CQL expressions can
sometimes deviate from normal CSS syntax (of course a pre-existing one
could be forked and modified.) I think parboiled[1] might be a better
option than JParsec (just a hunch, I have little experience with either.)
And as a general strategy note, if I were working on a Java port, I would
probably just start from the existing code and port one class at a time.
The SBT project is already configured for mixed Java/Scala sources so this
would (theoretically) allow the port to be completed without ever giving up
the unit test suite. Maven can be set up that way as well, but I'd
probably wait until the project was pure Java to make the build tool
transition.
[1]:
https://github.com/dwins/geoscript.scala/tree/master/geocss/src/main/scala/org/geoscript/support/logic
[2]:
https://github.com/dwins/geoscript.scala/tree/master/geocss/src/main/scala/org/geoscript/support/graph
[3]: https://github.com/sirthias/parboiled/wiki
--
David Winslow
OpenGeo - http://opengeo.org/
On Thu, May 30, 2013 at 5:00 AM, Andrea Aime
<[email protected]>wrote:
> Hi,
> at GeoSolutions we are considering a port of the CSS module to Java, under
> funding geared to "promote the CSS module with the direction of making it,
> in the future, a core module".
>
> Now, the work would not go as far as trying to push the CSS module into
> core, the idea would be to make it a supported extension, but in such a way
> that it's possible, if the module gets enough users, to turn it into a core
> module without further modifications.
>
> Given the recent discussion about usage of non Java languages in
> community, extension and core modules, the only way to ensure a possible
> core future for the CSS module is to rewrite it in Java
>
> First off, I would like to ask if anybody else would be interested, now or
> in the future, to work on the Java version of the module.
> Secondly, I would like to hear what would be the future of the Scala
> version of the module if there was a Java port of it: would we end up with
> a single module, or two competing modules that get evolved in separate ways?
>
> One issue I see in the port is about limits in the documentation, as far
> as I understand the current documentation is lagging behind the actual
> module abilities, and in order to do a full port one would really have to
> dig into the Scala code to see what's actually supported.
>
> The other is technological, parsing CSS can be done in several ways.
> The classic approach would be to use a JavaCC parser, an old technology
> that is however already used in GeoTools and GeoServer for CQL, ECQL, and
> WCS rangesubset parsing.
> Some pre-existing CSS parser grammar could also be used to help in the
> work:
> http://cssparser.sourceforge.net/
>
> Of the many open source parser generators in Java (
> http://java-source.net/open-source/parser-generators) I guess the other
> famous one is Antlr, people speak well of it, but it carries around a
> rather large runtime dependency that JavaCC does not need.
>
> Another approach would be to give up parser generations and go with with a
> parser combinator approach, which is the same as the Scala approach
> (supposedly, it might make the port easier).
> The only library I've found supporting this approach in Java is JParsec,
> http://jparsec.codehaus.org/Downloads
> Looks nice and easy to use, however there are a few gotchas:
> * does not have a community
> * there is no version control, just the source of the 2.0.1 release
> I've mailed a bit with the author, he confirmed that the library is
> "done", received no bug reports and thus made no more releases.
> Now, the source code builds, and after some manual tweaking of the
> build.xml file, there is a ton of tests too that pass properly.
> However... if there is any issue, we'll be on our own...
>
> Any other options?
>
> And more in general, what's the community feedback on this matter?
> Hopefully David will chime in too.
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer training in Milan, 6th & 7th June 2013! Visit
> http://geoserver.geo-solutions.it for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
