Component Type (Buckminster)

< To: Buckminster Project

Definition

The Component Type understands the content of a component and is responsible for producing a Buckminster Component Specification (CSPEC) containing dependency information for the component.

Description

Contrast the Component Type with the Reader Type (‘‘the reader’‘) that knows how to read and materialize the content. Currently, Buckminster contains the following component types:

• eclipse-project
• eclipse-installed
• jar
• maven
• unknown
• buckminster

Component Type is an extension point

It is expected that Buckminster is used in environments where components exist in various types of repositories. Some are very simple (one branch and only a latest version, no embedded or derivable dependency information), to complex components in a competent configuration management system where dependency information is either manually maintained, or calculated automatically. Hence, the Component Type is an Buckminster Extension Point, and some of the existing types have further extension points.

New component types can be added using the extension-point org.eclipse.buckminster.core.componentTypes.

The Eclipse Component Types

As you may have noted, there are two different component types associated with Eclipse, the standard eclipse-project, and eclipse-installed. The distinction between the two is important. The eclipse-installed component type is most commonly used for components that are deployed in your Eclipse runtime. When used together with the eclipse reader, it will derive the CSPEC from the Eclipse internal (in-memory) model maintained by the runtime. You may also use it together with other reader types. When you do, the CSPEC information is derived from the component manifest files (i.e. META-INF/MANIFEST.MF, plugin.xml, feature.xml, fragment.xml).

The eclipse-project type is the standard component type for software assets maintained with Eclipse (i.e. feature, plugin, fragment, or other). The eclipse-project type knows that there will be a .project file inside the software asset, and there it finds different Eclipse natures. Based on the natures it can determine what kind of Eclipse maintained software asset it is looking at (feature, plugin, fragment, or other).

Then the component type will use the reader to find specific files known to reside in the component. An Eclipse plugin will for instance always have a META-INF/MANIFEST.MF that contains the plug-in's OSGi dependency information. An Eclipse feature will have a feature.xml where dependencies for that feature can be found.

Extending the automatically generated CSPEC

It is possible to extend the automatically generated CSPEC with additional information. This is done in a file placed in the component root called "buckminster.cspex". It is an XML file and you can construct it using your favorite text editor, but preferably you should use an editor that understands XML-Schema and can assist you with code-completion and other nice features. You can read more about the relevant XML-schemas here.

The cspex is a true extension, it does not make copies of anything. It contains special elements that will allow you to add, modify, or remove the elements present in the constructed cspec.

We are considering moving the .cspex artifact (and all future buckminster specific artifacts that can be considered part of a component) to a special .buckminster directory (also in the root). The reason for the current, somewhat naive approach is that it is similar to how the Eclipse PDE manages its files (plugin.xml, feature.xml, etc.)

About ICSPecPackingBuilder implementation

Internally, the Eclipse component types delegates the work of building the Component Specification to a suitable implementation of the ICSpecPackingBuilder interface. It is only the eclipse components that use this separation. All other types will implement both the IComponentType and the ICSPecPackingBuilder interfaces with one single class.

The CSpecPackingBuilder is a Buckminster Extension Point (meaning, that if you are an implementer and would want something special, or support some other Eclipse type component, it is easy to extend the functionality already provided).

Support for update sites

Update sites are not yet supported as sources for components that can be materialized into your workspace.

There is however support for update sites in Buckminster as such are used in populating the Eclipse runtime used with needed plugins when materializing into a workspace. For more information see Buckminster UpdateSitesInHeadlessMode.

The buckminster component type

This component type is useful for software assets that have no derivable component specification information, or where a specific Component Type has not been created. To use the buckminster type the owner of the asset must add a manually created (and maintained) CSPEC file inside the software asset. The manually created and maintained CSPEC should be placed in the component's root and be called "buckminster.cspec". Just as for the eclipse-project it is also possible to extend the "buckminster.cspec" with additional information. This is done in a file placed in the component root called "buckminster.cspex". Both the .cspec and the .cspex file are XML files and you can construct them using your favorite text editor, but preferably you should use an editor that understands XML-Schema and can assist you with code-completion and other nice features. You can read more about the relevant XML-schemas here.

We are considering moving the two artifacts (and all future buckminster specific artifacts that can be considered part of a component) to a special .buckminster directory (also in the root). The reason for the current, somewhat naive approach is that it is similar to how the Eclipse PDE manages its files (plugin.xml, feature.xml, etc.)

Is this true, will it, or has it moved?

The jar Component Type

The jar type can download a jar-file and will treat it as a component in its own right. A CSPEC will be generated that has no dependencies. This type is intended to be used when you want to depend on a jar known to be found using a common URL. It is also a good start when you want to write something that can download from an ftp or http based repository that has a known structure. One widely used such repository is the global Maven repository at http://www.ibiblio.org/maven/ where a large number of open source components can be found. See more about the Maven component type below.

The Maven Component Type

The maven type is basically a jar type, but a Maven repository also contains dependency information that Buckminster can use. The functionality to understand the dependencies in a Maven repository resides in the maven. It is capable of reading, not just the jar-files, but also interpret their names (composed by component and version information) and to find the associated Maven specific 'pom' file. The 'pom' file in turn, contains dependency information that the maven is able to parse and thus enable transitive resolvement.

For further information about Maven consult Maven at Apache