If i recall the conversation correctly it seemed like there was an
informal consensus that only the core of GeoServer be kept to pure java. My
opinion was that extensions or community modules could be implemented in
other languages as long as those modules had a stable maintainer.
On one hand as a newbie to scala I can appreciate a pure java port as it
would allow me to contribute more efficiently. On the other hand I think
this sets a bad precedent. We have an active maintainer who is maintaining
a module that has more than a handful of users. I certainly can't speak for
David in this case but if i were contributing to a project that did this to
me I wouldn't be a contributor for very long.
$0.02
On Thu, May 30, 2013 at 3: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
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
