On Thu, May 30, 2013 at 10:24 PM, Justin Deoliveira <[email protected]>wrote:
> 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.
>
This is correct. The CSS module predates GeoScript Scala, and although I
have merged it in at the source level it does not have any dependency on
the rest of GeoScript. There is a small (one or two methods) Java
compatibility API which is what the Groovy version of GeoScript uses. I'll
also toss in that Scala is not really a "scripting language" in any
significant sense - the code is compiled to normal Java bytecode (albeit
sometimes with funny method names) and the normal classloader rules apply
in terms of unused classes not taking up PermGen space, etc. Scala classes
do tend to be a little more PermGen heavy than Java ones though, since some
Scala idioms are compiled into lots of small classes or methods, and I'm
not trying to discount the cost of having yet another collections and
parser library loaded.
> 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?
>
Essentially this is the situation we are in now, but with the CSS module
promoted to extension status, right? This is fine with me.
On Andrea's notes about extensions, I think that if a client wants to use a
module but can't because their policy is not to use extensions, that's not
a very good reason to bring the extension into core. Maybe we should be
investigating how to overcome this perception that extensions are not well
supported (they are endorsed by the project, right?) Or maybe a technical
solution would be to add some extension management facilities
(enabling/disabling, graphically installing, etc) in order to make it
easier to reduce the PermGen and other impacts of GeoServer's growing core.
--
David Winslow
OpenGeo - http://opengeo.org/
On Thu, May 30, 2013 at 9:06 AM, Andrea Aime
<[email protected]>wrote:
>
>> On Thu, May 30, 2013 at 5:00 PM, David Winslow <[email protected]>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.
>
------------------------------------------------------------------------------
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
