201311harvesting

On the last year, the initial code structure has been heavily upgraded to new ways of developing which makes developing and modifying custom geoNetwork instances easier.

This requires extending the spring framework migration to define plugins for services and harvesters and breaking them out into separate modules. For services we could split some of them into separate modules like, statistics, region, thesaurus, etc...

Develop and testing of new harvesters and services will be much easier after this improvement. This is a refactoring that, although it will not lead on improvements on a user point of view, will simplify the maintenance of the code. After this refactoring, new services will be be added as maven dependencies, which can lead to easier development and customization of services.

The proposal is to focus on harvesters, as a first attempt to finally migrate all services to Spring MVC and have a strong geoNetwork backend.

The aspect of running processes on harvested metadata should be considered. At a harvest one should be able to change url's remove contact info and so on. The administrator can select an xslt for a harvester.

A harvester could be available that scans a file-drive (or SDE) for metadata. It would improve intregation of data and metadata (since the metadata is maintained close to the data). To have tracability a previous version of a harvested record should be stored, if a modification of the metadata is notices (store md in SVN/Git).