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.
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.
Contents
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
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
TBD