Promote CSS Styling module to extension.

Motivation Proposal Backwards Compatibility Feedback Voting Links

Saul Farber

2.3.4

Under Discussion, In Progress, Completed, Rejected, Deferred

The CSS styling extension has lived in the community modules area for a few years now. As clients of developers are starting to request a supported version it is time to promote to extension status.

Minimally, the CSS module can simply be refactored to use the ``org.geoserver.extension`` package instead of ``org.geoserver.community``. However, the GeoSolutions team is offering some time to improve the level of integration in the extension.

On the backend, integration could be improved by adding support for non-SLD styles to GeoServer’s Catalog API.

On the frontend, the CSS styling extension adds a separate page for editing CSS styles and does not update the normal style editing page. A user attempting to edit a CSS style through the normal style editing workflow will be presented with the auto-generated SLD and any changes to this will be overwritten the next time the CSS is modified. The CSS editing workflow should be unified with SLD, and a few extra additions to the CSS editing page (a submit button that does not navigate away from the editor page, tools for configuring the layer associations for the style, a preview map) would be equally applicable to SLD styles and could be integrated into the main style workflow.

The GeoServer developer manual sets forth the following requirements before a module may be promoted to extension status:

• The module has at least a “handful” of users (at least three.) \\ \\ Based on mailing list traffic I think this requirement is met - at least three unique users have asked questions regarding the CSS extension recently.
• The module has a designated and active maintainer. \\ \\ I (David Winslow) would be the designated maintainer for this extension.
• The module is considered “stable” by the majority of the PSC. \\ \\ This proposal was discussed on the developer mailing list and no stability concerns were raised yet.
• The module maintains 40% test coverage. \\ \\ The underlying library which provides CSS-to-SLD translation has test coverage of about 75% (code coverage instrumentation is not set up as part of the regular builds.) The Wicket code in the GeoServer community section has low coverage but will need to be rewritten as part of the GUI integration work discussed above.
• The module has no IP violations. \\ \\ The Scala standard library is under an uncommon license, but an unrestrictive one. We’ll need to ensure that we distribute a copy of it with the extension. The geocss library is under the MIT license.
• The module has a page in the user manual. \\ \\ Yes, the manual contains a brief tutorial and a few reference pages.
• The maintainer has signed the GeoServer Contributor Agreement. \\ \\ Yes.

In modifying the catalog to support non-SLD styles some changes to the on-disk format will be required. I believe this can be accomplished such that only configurations actually using CSS styles will encounter backwards compatibility problems.

Andrea Aime: +1 Ben Caradoc Davies: +1 Phil Scadden: +1

JIRA Task