Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Proposed Kepler Collaboration Model Structure

This section allows us to discuss proposed implementations of the collaboration model for Kepler that will allow different tooling and technologies to share in a common format information that can be used to collaboratively work with or consume a project.

Introduction

The high-level architecture of the Kepler project is to promote collaboration on software development projects. Though the underlying technologies are based around providing a common language to express both information about the projects and the collaboration infrastructure that it uses.

The Kepler Collaboration model is a simple XML syntax that allows the core concepts of a project to be shared and then enriched by facets. A facet is a collection of information that represents a concept - an example of this might be mailing lists where the facet captures all information for mailing lists. The purpose of a facet is both to capture the information in a structured way but also to allow tooling and adapters the ability to state which facets that require/support. Holding these requirements and capabilities of the adapters and tooling at this less granular level will allow the Kepler infrastructure to quickly determine whether a certain adapter can provide such information and also whether tooling (such as mailing list views) should be presented by virtue of the presence or absence of a facet within the projects collaboration model.

The Core Model

Kepler Schema project-core

In order to provide a structure which is simple enough to support almost all existing understood software project development the Kepler project has been looking to understand the types of meta-data that exists in the current state market. The aim of this is to offer a simple core model that provides validated and understood structure for a project. The range of additional meta-data that exists can be handled through extension facets which can be attached to the core model concepts.

The primary elements of the core model are as follows:

Project

At its heart the collaboration model is defined to hold information about a project - a project is a unit of work that can be collaborated on.

Version

A version is the concept of a fixed release of the project, this really snapshots information about the project at that point in time and allows for an understanding of the effect of time over a project. Also the version captures the concept that the team collaborating will make releases which are consumable by other developers in a binary form.

Project Facet

A project facet is an extension unit of a project that can hold information regarding different aspects of the project - this meta-data about a project can then be leveraged by tools and users of the collaboration model to help identify and manage the projects they wish to consume and work on, this would include:

  • Understanding the project's identification, taxonomy and releases
  • Finding resources for the project - documentation, issue tracking, build servers
  • Understanding the structure of the project - directory structure, build system in use
  • Understanding the licensing and use of the project

A facet is a namespaced extension of the project facet type and each facet type must only appear once under a project. This course grained structuring is in place to make it easier to parse and understand.

Version Facet

A verison facet offers the same functionality as a project facet, however is allows for meta-data to be stored at the version(release) level.

Artifact

TBD

Artifact Facet

TBD

Relationships and Dependencies

Kepler Schema dependency

Back to the top