Skip to main content

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.

Jump to: navigation, search

Buckminster Project/docs/drafts/DependencySpec

Buckminster Dependency Specification

Buckminster creates component dependency graphs using a Dependency Specification, henceforth referred to as "dspec". A dspec is either obtained using a dspec builder or exists as a physical file in the component that it defines. Buckminster delivers dspec builders for Eclipse update-site's, features, plug-ins, and fragments. New builders can be added as needed (see Component type).

DSpec elements

A dspec defines the top-level element dependencies as a list of dependency elements.

A dependency consists at least of a component name. The dependency may optionally contain a version designator and a version type.

A dependency graph is always implicit since dependencies appoint other components and all components can be viewed in terms of a dspec. This implicit graph must be a Directed Acyclic Graph (DAG).

One of the fundamental concepts of  Buckminster is that a component does not really have any dependencies unless you do something with it. The dependency graph might be very different for different needs. This very important extension to the overall concept is covered by the Action Specification. A free standing Dependency Specification can be seen as an Action Specification with one single action that requires all dependencies and imposes default behavior for the resolution.

Version Designator

A version designator appoints the specific component versions that will satisfy a component request. It uses the semantics similar the OSGi Version Range and appoints versions using a mathematical interval notation. See Mathematical Convention for Interval Notation. The notation "2.3.4" is equivalent to the mathematical range "[2.3.4,∞)". The version designator differs from the OSGi range in that the version in itself is interpreted by a version type. OSGi uses a fixed major.minor.micro[.qualifier] scheme.
 

Version Type

The type knows how to parse and compare versions. Buckminster comes with the following predefined version types:

OSGi
Assumes that the version has the following grammar:
    version   ::= major( '.' minor ( '.' micro ( '.' qualifier )? )? )?
    major     ::= number // See 1.4.2
    minor     ::= number
    micro     ::= number
    qualifier ::= ( alphanum | ’_’ | '-' )+

String
Will allow any string that does not contain the characters that delimit ranges.

New version types can be added using the extension-point org.eclipse.buckminster.core.versionTypes.

Back to the top