GSIP 185

GSIP 185 - Promote Web Resource to Extension

Overview

The community module web-resource to an extension.

Proposed By

Jody Garnett (GeoCat) is proposing this activity to better support our customers using GeoServer in a hosted environment (without direct shell access).

Assigned to Release

This proposal is for GeoServer 2.17-beta.

State

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

Motivation

GeoServer Resource API provides programatic management of configuration files and icons. The REST API makes this functionality available for automation, we would like to make web-resource module an extension to offer this capability to web administration application.

The web-resource extension is successful in meetings its objectives:

• The primary motivation is to manage icons, fonts and symbology associated with the the style editor.
• The secondary motivation is to directly edit configuration files such as image mosaic, app-schema and free marker templates to do not provide their own user interface.

Proposal

Preflight:

0. Move from Tools to Data, and test functionality.

Proposal covers:

1. Moving the module from community to extension in the build system.

2. Updating the website template to make the extension available.

3. Updating the pom.xml contract information.

4. Writing documentation for the extension:

   • Installation
   • Reference page for the user interface
   • Example of uploading an icon to a styles folder
   • Example of editing an app-schema configuration file
   • Example of editing control-flow configuration file

Backwards Compatibility

This extensions is strictly additive and does not have any backwards compatibility implications.

Feedback / Discussion

Discussion

The module itself warrants some discussion:

• Jody has found production use of the Resource REST API being used to modify security configuration files (this works as those files are 'watched'). Is this a capability we wish to support, or should these files be blacklisted now that there is some ability to manage these files via their own REST-API?

  Email discussion notes this as any administrator should know what they are doing here.

Extension Requirements

The developers guide lists several requirements for community modules graduating to an extension:

1. The module has at least a “handful” of users

   • GeoSolutions has observed a number of sites running the module, at least 3 recently.

2. The module has a designated and active maintainer

   • Andrea Aime (GeoCat) is willing to act in this capacity.

3. The module is considered “stable” by the majority of the PSC

   • The module has been unchanged and working for several releases.

4. The module maintains 40% test coverage

   • Module has 84% test coverage as reported by IntelliJ "run with coverage"

5. The module has no IP violations

   • Module was largely written by Niels in 2015, he signed the CLA

6. The module has a page in the user manual

   • It does indeed

7. The maintainer has signed the GeoServer Contributor Agreement

   • OSGeo CLA signed

Voting

Project Steering Committee:

• Alessio Fabiani:
• Andrea Aime:
• Ian Turton:
• Jody Garnett:
• Jukka Rahkonen:
• Kevin Smith:
• Simone Giannecchini:
• Torben Barsballe:
• Nuno Oliveira:

Links

• GEOS-9877