From: Justin D. <jde...@op...> - 2013-05-31 02:24:18
|
Regarding the version tracking of geotools and geoscript.scala, i thought (and david can correct me here) that geocss could be used standalone. I believe Jared makes use of this in the groovy geoscript implementation without having to pull in all of geoscript.scala. With that said, I would suggest the following course. With David's consent let's go through the motions and promote the css module to an extension. In the meantime obviously anyone that wishes to work on a pure java port is free to do so, perhaps starting it as a community module. If it gets to the point where it is stable and can become a replacement we can evaluate pushing it into core or promoting it as a separate extension. Thoughts? On Thu, May 30, 2013 at 9:06 AM, Andrea Aime <and...@ge...>wrote: > On Thu, May 30, 2013 at 5:00 PM, David Winslow <dwi...@op...>wrote: > >> FWIW, the code that is actually stored in the GeoServer source tree for >> the CSS module is mostly Java (I made some error in transliterating >> CSSDemoPage.scala and had to revert it.) Does it affect fitness-for-core >> if the Scala code is all behind a managed Maven dependency? >> > > Yes, that does not change some of the reasons against having modules in > core that are made with scripting languages: > 1) forced dependency on a large runtime that makes it hard to start > GeoServer without tweaking max permgen > 2) dependency on an external library that is a one man job and that does > the 99% of the actual job, that is, if you need to > do any improvement to it, you have to program it in Scala, and need to > be able to publish updates to the library in a timely > manner (compare with the GeoServer dependency on GeoTools). > I mean, if this was something generic like common-utils who cares if > it's a one man job, you can > work on top and around of it, but with CSS processing being fully done > in Scala, there is no other option than getting into it. > > Also, the CSS Scala code is based on GeoScript and thus on GeoTools no? So > I guess we'd also need multiple supported versions > of it, one per version of GeoTools used, and have updates over time as > GeoTools versions are released and used in GeoServer > releases. > > 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 > > ------------------------------------------------------- > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. |