The community module web-resource to an extension.

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

This proposal is for GeoServer 2.17-beta.

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

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.

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

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

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.

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

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

   • It was include in Boundless Suite, not sure how many users?
   • GeoCat is committed to supporting our customers use of this module, but wishes to see the functionaly incorporated into core or set up as an extension first.

2. The module has a designated and active maintainer

   • Jody Garnett (GeoCat) is willing to act in this capacity, would prefer to see two maintainers of course.

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 86% test coverage

5. The module has no IP violations

   • Module was largely written by Niels under contract to Boundless, with appropriate OSGeo CLA signed.

   • It is worth checking headers as part of this activity.

6. The module has a page in the user manual

   • Requirement noted in proposal plan. Intend to have reference material and a couple of examples.

7. The maintainer has signed the GeoServer Contributor Agreement

   • OSGeo CLA signed, GeoServer Contributor Agreement no longer used.

Additional graduation considerations:

8. User interface review

   • The user interface is functional, the tree-view has caused some upgrade concerns when updating wicket.

   • The text editor provider should be reviewed for consistency with the style editor.

     May end up creating a feature request to work on later.
     

9. REST API review

   • The Resource REST API is already part of GeoServer. This user interface should offer web admin users the same level of configuration access provided by REST API.

10. Security considerations

• By its nature this module allows some visibility to administrators confident with accessing the data directory file system directly. The contents of the security folder, and workspace folders are available. Any credentials stored in data store configurations would be visible for example.

  This is no different from the capabilities of the REST API Resource endpoint.

Project Steering Committee:

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

• GeoTools / GeoServer Meeting 2019-03-01
• GEOS-9524