Proposal: Schema plugin improvement
| Date | 2014-08-20 | Contacts | Francois |
| Status | In progress | Release | 3.0 |
| Resources | Available | Ticket # | #615 |
| Source code | https://github.com/fxprunayre/core-geonetwork/tree/improvement/schema-plugin-bean | ||
| Funding | Wallonia region (metawal) | ||
Currently, schema plugins are deployed in a GeoNetwork node by copying the folder in the schema_plugins directory. Therefore, some (Java) parts of the application expect to mainly deal with ISO19139 or ISO19139 profiles. Current schema plugin architecture cover most of the needs (viewing, editing, indexing, processing of metadata records) but some other aspects need improvements (eg. search for relations, multilingualism).
The current proposal add a Java bean for each schema plugins which will take care of some actions on the metadata which are currently only working with ISO19139 and are not pluggable with the current mechanism. The bean provide support for custom:
- search for relation (https://github.com/geonetwork/core-geonetwork/blob/develop/services/src/main/java/org/fao/geonet/guiservices/metadata/GetRelated.java#L209)
- multilingual editing (https://github.com/geonetwork/core-geonetwork/blob/develop/services/src/main/java/org/fao/geonet/services/metadata/EditUtils.java#L290)
There is no changes to the schema configuration folder. It only needs to be moved to a maven module.
Those changes will be required to add the ISO19115-3 plugin (https://github.com/geonetwork/schema-plugins/tree/develop/iso19115-3).
A new maven module named "schemas" is added. The following child modules are defined:
- schema-core (depending on common): Define SchemaPlugin abstract class
- one module for each schema plugins.
Each schema plugin are migrated to a maven module having the following structure:
The schema plugin bean is optional and needs to be defined only if the plugin support features like association of resources, multilingualism ...
For example, ISO19139 bean implements both MultilingualSchemaPlugin and AssociatedResourcesSchemaPlugin interface, and dublin core only implement AssociatedResourcesSchemaPlugin.
The following approach can be used When user need to check if the plugin support an interface (eg. https://github.com/fxprunayre/core-geonetwork/blob/improvement/schema-plugin-bean/services/src/main/java/org/fao/geonet/services/metadata/EditUtils.java#L310):
SchemaPlugin schemaPlugin = SchemaManager.getSchemaPlugin(context, "iso19139");
if (schemaPlugin instanceof MultilingualSchemaPlugin) {
To register a new schema to the build:
- create the maven module (and the optional bean configuration https://github.com/fxprunayre/core-geonetwork/blob/improvement/schema-plugin-bean/schemas/iso19139/src/main/resources/config-spring-geonetwork.xml)
- register it in the web module:
- in the copy-schemas execution https://github.com/fxprunayre/core-geonetwork/blob/improvement/schema-plugin-bean/web/pom.xml#L537
- (optional) as a dependency (https://github.com/fxprunayre/core-geonetwork/blob/improvement/schema-plugin-bean/web/pom.xml#L460) if the schema has a bean to be loaded.
When running the application using mvn jetty:run use the following to update schema to the running web application:
cd web
mvn process-resources
Schema plugins migrated to the new structure:
- core-geonetwork repository (all)
- csw-record
- dublin-core
- fgdc-std
- iso19115
- iso19110
- iso19139
- schema-plugins repository
- iso19115-3
- iso19135
In this proposal, the following changes to the schema-plugins repository (https://github.com/geonetwork/schema-plugins) should be applied:
- create a 2.10.x branch in order to preserve current schema structure working with 2.10.x series
- rename master branch to develop (to have same naming as in core-geonetwork repository)
- in develop branch, remove the first draft implementation of iso19115-1 (https://github.com/geonetwork/schema-plugins/tree/master/iso19115-1-2013) - iso19115-3 replace it
- Type: architecture
- Module: schema plugins
- Discussion on the ML: http://osgeo-org.1560.x6.nabble.com/Schema-plugin-changes-td5157329.html
- Vote Proposed: 22/08/2014
- +1 from Jesse, Francois
Other area of the application could also benefit of this change but require more work:
- MCP profiles use custom creative commons licensing
- CSW typenames/output schema parameter may be defined per schema
- Dynamic loading of schema are not supported for schema having a bean (require to load a JAR after schema upload)
- All