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"
(New page: 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 ...) |
|||
Line 1: | Line 1: | ||
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. | 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. The concept of 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" |
Revision as of 17:49, 30 July 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.
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. The concept of 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"