Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Proposed Kepler Collaboration Model Structure"
(→Introduction) |
|||
| Line 5: | Line 5: | ||
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 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. | + | 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 == | == The Core Model == | ||
Revision as of 15:41, 14 August 2007
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 provide 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