wiki:ComponentRegistryAndEditor

Version 39 (modified by Twan Goosen, 8 years ago) (diff)

Updated requirements, added new front end requirements

Project: Component Registry

The Component Registry stores CMDI metadata components and profiles and offers a REST service to list, retrieve, store and modify them. The front end is a separate web application that acts as a client of the Component Registry REST service and displays available components and profiles in the registry in addition to offering an editing interface for the creation, modification and publication of components and profiles.

The Component Registry has means to keep itself coherent and consistent: check all offered components and keep an administration of the added and removed components. All components get a unique identifier wherewith other applications can identify it to the registry.

Components and profiles are specified and stored in a format specified by the general component schema. The registry offers profile schema's in the XSD format, which get generated from the profile specifications on the fly using the comp2schema XSLT.

Documentation for the new Javascript based front end can be found at its GitHub wiki pages.


Subpages

Contents

  1. Project: Component Registry
    1. Subpages
    2. Contents
    3. People
    4. Getting code
    5. System Requirements
    6. Development process
    7. Milestones and Planning
    8. Building and Deploying
      1. Building
      2. Deployment
      3. Dependencies
    9. Management
      1. Administration interface
      2. Managing user groups
    10. Design
    11. Tickets
    12. History
      1. Historical pages


People

  • Project owner: Twan Goosen

People who have worked on the Component Registry and Editor in the past:

  • Patrick Duin (original developer)
  • Jean-Charles Ferrières (developer back end)
  • George Georgovassilis (developer back end)
  • Olha Shkaravska (developer front/back)
  • Mitchell Seaton (React front end prototype)

Getting code

The source is available from the Clarin SVN repository (ComponentRegistry/trunk).


System Requirements

To serve:

  • Java 1.7
  • Tomcat 7
  • PostgreSQL server

To use the front-end:

  • Web browser with Javascript support
    • Tested with Firefox 43.0, Google Chrome 48.0, Safari 9.0

To build:

  • Java 1.6
  • Maven 2
  • Flex SDK 3.6

To run the Flex client (pre-2.0):

  • Web browser
  • Adobe Flash Player

Development process

  • Feature implementations and fixes are assigned to milestones; one milestone per minor version
  • Active development happens in trunk
  • As soon as the items on the version milestone have been reached, a branch is created (e.g. 1.15.0) and minor version number in trunk is bumped
  • The branched version gets deployed to a testing server (lux16) and is tested internally at MPI-PL (by Corpus Management) according to a test plan. For this, create a testing ticket on the MPI TRAC.
  • Once testing has completed successfully, the new version gets deployed to the production server (catalog.clarin.eu, see ServerConfig? for info and contacts). For this, create a deployment ticket on the MPI TRAC.
  • The deployed version gets tagged
  • Development for the next minor version continues in the trunk
  • Maintenance releases may be done to the current production branch (leading to e.g. 1.15.1)

Milestones and Planning

There are 3 milestones to go:


Building and Deploying

For specific information about building and deploying the separate modules, see their respective pages:

Building

There is a modular Maven project (pom) that contains both the REST service and the Flex UI.

Deployment

To deploy the REST service including the Flex UI and its HTML wrapper, deploy the build output (WAR file) of the REST service to a Tomcat instance.

For details, see deploying Component Registry REST service.

Currently Deployed Locations

Dependencies

Internal dependency: the REST service depends on the Flex UI because it contains an html wrapper for the SWF.

External dependencies: see REST service dependencies.

The Component Registry as a whole also depends on the metadata toolkit, specifically the general component schema and the comp2schema XSLT.

Management

Administration interface

An administration interface that allows for inspection and modification of all public and private components is available at the path /admin.

E.g. for production: http://catalog.clarin.eu/ds/ComponentRegistry/admin].

Which accounts have administration rights is configured in the context parameter eu.clarin.cmdi.componentregistry.adminUsers.

Managing user groups

As of version 1.14.0 of the Component Registry, group functionality is available. Groups can be managed, either through a JMX interface as described in ComponentRegistryAndEditor/ManagingGroups or through the Admin interface (select 'Manage groups' at http://catalog.clarin.eu/ds/ComponentRegistry/admin).


Design

For design details of the modules of this project, see their respective pages:

There is a description of the high level architecture (picture below).

High level overview of Component Registry


Tickets

List of all open tickets for this project:

Ticket Summary Priority Owner Milestone
#130 Importing component/profile should strip out components with componentId attributes. major Twan Goosen
#155 error message when not enough attributes to login major Twan Goosen
#164 Copy data category properties into component/element major Twan Goosen
#186 Transfer ownership of components major Dieter Van Uytvanck
#379 Throw exceptions from update method of ComponentRegistry interface major Twan Goosen
#428 Examine why ConcurrentRestServiceTest does not fail major Twan Goosen
#735 Data category should be searchable in the CCR major menzo.windhouwer@di.huc.knaw.nl
#147 Add a parameter to link to the components/profiles tab minor Twan Goosen
#221 add a favicon for the component registry minor Twan Goosen


History

The Component Registry has been developed as part of the CLARIN project.

People who have worked on this project include (in chronological order) Patrick Duin (original author), Twan Goosen, Jean-Charles Ferrières, Olha Shkaravska and George Georgovassilis

The original implementation of the backend (REST service) was using file system storage for the users and their registries. As of ComponentRegistry-1.8 this was replaced by a database based implementation. The code still reflects the original, more hierarchical storage model (e.g. a registry per user even though all components are stored in the same table).

For a detailed version history, see the changelog.

Historical pages