Bricklaying with Buckminster

That naming process can, if required, specify details such as the version number of a component. This information will usually incorporate the RMAP – Resource Map – a URL or similar reference identifying the possible libraries or repositories where that component can be found. If that target component is itself constructed from other components, the RMAP will also list the repositories where all the components can be found.

The RMAP also allows developers to define specific search paths through the developers' local and wider resources, if required. This allows them, for example, to set a path that starts with their own repository if they have one, then the team's repository, and so on out through corporate repositories and onto external public sources such as the Eclipse CVS respository. Buckminster is able to work with most forms of repository, ranging from databases and file systems at one end through to CVS, SVN or Maven repositories at the other. The key is that Buckminster is equipped with a component reader relevant to that source.

There are a couple of specification concepts which govern the components themselves and the way they are materialised. The Component Specification (CSPEC) is a file containing all the metadata about that component, such as its dependencies upon other components. If the components are Eclipse generated, for example plug-ins, then this file will normally be generated automatically by Buckminster. There is a variant on CSPEC, known as CSPEX, which is used when the specification needs to be manually written.

The Materialisation Specification (MSPEC) controls the way in which downloaded components materialise into specific folder or directories on a target computer. For example, it can accommodate the way in which a component may need to download slightly differently to the workstations of a development team, depending upon the type of workstation – Windows or Linux for example – individuals favour.

The BOM is the Bills Of Materials of a component. It is generated automatically by Buckminster and contains a complete list of everything needed to materialise the component, including the locations and versions. It can also be used as a publishable entity so that all consumers of a component or service get exactly the same instances of the components specified, selected from the same repositories.

This ensures that consumers get the specified service or application that has been set down for them rather than the first located example of any version of a named component. It can also mean that different user communities can be specified with different versions of the same components, a capability that can be vital to different implementation applications where issues such as corporate governance or compliance to legislative or operation rules form a core part of business policy.

Using the Eclipse version numbering, Buckminster is still at Version 0.1.0 and is only expected to get to Version 0.4.0 over the next 12 months. So it is still some way from being a viable tool for any but the early adopters amongst the developer community.

But as greater usability, support for a wider range of component models and support for more languages is added it can be expected to get closer to being a tool that makes the development applications and services a more flexible and faster task. Developers thinking of joining that early adopter community can download the latest build of Buckminster here. ®