|
|
| Line 1: |
Line 1: |
| | #REDIRECT [[Why Buckminster ?]] | | #REDIRECT [[Why Buckminster ?]] |
| − |
| |
| − | {{Backlink|Buckminster Project}}
| |
| − | =Welcome to Buckminster=
| |
| − |
| |
| − | <p>If you've already read this introduction, you can skip straight to the rest of the [[:Category:Buckminster Key Concepts|Key Concepts category]] for more in depth information.</p>
| |
| − |
| |
| − | ==In Its Simplest Form==
| |
| − |
| |
| − | <p>In its simplest form, Buckminster solves the following problem:</p>
| |
| − |
| |
| − | <ul>
| |
| − | <li>Your colleague says "OK, project Overland is ready for you to work on
| |
| − | - just check out <samp>com.megacorp.overland</samp> from CVS and get
| |
| − | started.</li>
| |
| − | <li>You checkout com.megacorp.overland and discover that it has unresolved
| |
| − | project dependencies.</li>
| |
| − | <li>"Oh yeah," he says, "you have to checkout project overwater
| |
| − | as well." Of course that doesn't completely solve the problem...</li>
| |
| − | <li>"Also you have to get the latest undersea.jar from the central FTP
| |
| − | server."</li>
| |
| − | <li>"But hey, it doesn't build ok!"</li>
| |
| − | <li>"Oh, I forgot, you have to import this jar here, and rename it... and let me see what else..."</li>
| |
| − | <li>Eventually, after a few rounds of this, you have the whole set of
| |
| − | resources and you are ready to go to work.</li>
| |
| − | </ul>
| |
| − |
| |
| − | <p>In its simplest form, Buckminster is a tool for materializing a workspace. As
| |
| − | a component developer, your workspace is the set of components you are working
| |
| − | on plus all of their prerequisite components. Under Buckminster, components are
| |
| − | projects. In pictures, the workspace (the cloud) is initially empty, then you
| |
| − | ask Buckminster to materialize the component (the box), after which the workspace contains
| |
| − | the component:</p>
| |
| − |
| |
| − | [[Image:image1.gif|thumb|center|300px|(Bear with us on these pictures - right now they are trivial, but soon Buckminster's complexity will make the pictures useful.)]]
| |
| − |
| |
| − | <p>Because component A has a dependencies on B & C which have a dependencies
| |
| − | themselves, the actual result is something like this:</p>
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image2.gif<br>
| |
| − | <i>Component A is the one you are working on;<br>
| |
| − | components B, C & D are required to be in the workspace.</i></p>
| |
| − |
| |
| − | <!--
| |
| − | [[Image:Image2.gif|thumb|center|300px|Component A is the one you are working on; components B, C & D are required to be in the workspace.]]
| |
| − | -->
| |
| − |
| |
| − | Although jumping ahead, a very common question at this point is if it is possible to materialize components with Buckminster without running the Eclipse user interface, for instance for the purpose of building a particular configuration on a remote server. The shortest answer to this question is: Yes, Buckminster can be used both as an integrated part of the Eclipse IDE, and from the command line where Buckminster will materialize a ''headless'' Workspace.
| |
| − |
| |
| − | ==Where Does Buckminster Get Things?==
| |
| − | <p>Once you've grasped that Buckminster materializes components, the next
| |
| − | big questions in your mind is probably "what are components?" and
| |
| − | "where does Buckminster get the components?". Components are
| |
| − | collections of files (a.k.a. resources) and are represented in Eclipse by
| |
| − | projects. Components can be retrieved from a variety of different repositories.
| |
| − | The most common repositories are a CVS repository or an FTP server, but almost
| |
| − | anything (databases, file systems, auto-generator programs, etc) can be used via
| |
| − | the <i>
| |
| − | org.eclipse.buckminster.core.readerTypes</i> extension point.</p>
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image3.gif<br>
| |
| − | <i>Component A being retrieved from a CVS repository <br>
| |
| − | and the required component B from an FTP server.</i></p>
| |
| − | <p align="left">Of course the story is a bit more complicated than the simple
| |
| − | picture because the component retrieval takes into account various version
| |
| − | naming schemes, but we'll get into that later. For now, this picture is good
| |
| − | enough.</p>
| |
| − | ===How Does Buckminster Find The Repositories?===
| |
| − | <p>So the next question you're asking yourself is how does Buckminster know
| |
| − | which component is stored in which repository? Knowing what you know about
| |
| − | Eclipse, you know the projects are linked to Team (CVS) repositories (or some other repository like Subversion). However
| |
| − | there are actually two concepts: the <i>component</i> and its <i>storage
| |
| − | location</i>. Separating these two concepts is like separating interface and
| |
| − | implementation in good software design. Buckminster does this separation through
| |
| − | a level of indirection known as a <i>resource map</i>. The resource map (rmap)
| |
| − | provides location information for families of components. When Buckminster needs
| |
| − | to load component A, it looks in the rmap to determine the repository containing
| |
| − | A, then goes to that repository and loads A. Then because A requires B and C,
| |
| − | Buckminster looks in the rmap for information on B and C, goes to those
| |
| − | repositories, loads those components, and so on.</p>
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image4.gif<br>
| |
| − | <i>The resource map maps components to storage locations.</i>
| |
| − | </p>
| |
| − |
| |
| − | ===Why Is The RMAP Useful?===
| |
| − | <p align="left">This separation of <i>component</i> and <i>storage location</i>
| |
| − | is useful because it allows Buckminster to retrieve the same component from
| |
| − | potentially many different storage locations. The rmap has a number of areas of
| |
| − | flexibility. First, the rmap defines storage locations for families of
| |
| − | components rather than single components. Thus one can say "find all the
| |
| − | Apache components on the Apache ftp server" without having to specify
| |
| − | "find Apache Struts on the Apache ftp server and find Apache Cocoon on the
| |
| − | Apache ftp server and find ..." ad nausea. Second, the rmap defines a
| |
| − | <i>search path</i> of storage locations to search for a component. Thus one can
| |
| − | say "first look in my local repository, then look in my team's repository,
| |
| − | then look in my corporate group repository, then look in the Eclipse public CVS
| |
| − | repository".</p>
| |
| − |
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image5.gif</p>
| |
| − |
| |
| − | ===One More Useful RMAP Feature===
| |
| − | <p>Last, but not least, the rmap allows variability by setting properties. This can be used for
| |
| − | many different purposes. One useful thing is for example to have different search paths for different
| |
| − | distributed development sites. Thus the rmap for Team Stockholm would list the
| |
| − | same component families as the rmap for Team Winnipeg, but with different local
| |
| − | repository servers. TCP round-trips from Canada to Sweden are slower than
| |
| − | TCP round-trips from Canada to Canada, thus the Winnipeg team maintains a
| |
| − | replicated CVS repository for certain components. </p>
| |
| − |
| |
| − | <p>Buckminster rmap-properties allows both teams to use the same rmap - the exact same file -
| |
| − | but to define a different <i>site</i>, and thus a different set of search paths.
| |
| − | Obviously the central servers (probably the last entry in each search path)
| |
| − | would point to the same central Swedish servers so that if the components were
| |
| − | not cached locally, they would be fetched across the Atlantic.</p>
| |
| − |
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image6.gif<br>
| |
| − | ''Components A,B, and C mapped to multiple repositories.''</p>
| |
| − |
| |
| − | ===Back to Simplicity===
| |
| − | <p>We have described many useful features of the resource map, but to avoid cluttering the
| |
| − | picture, let us retreat to the basics: the resource map (rmap) is mapping from <i>components
| |
| − | </i>to <i>storage locations</i>. </p>
| |
| − |
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image4.gif</p>
| |
| − | <p align="left">For details of the rmap, see [[Buckminster Resource Map|RMAP]].</p>
| |
| − |
| |
| − | ==What is a Component?==
| |
| − | <p>A <i>component</i>, in the Buckminster parlance, represents a collection of files or
| |
| − | sometimes one single file. For most Buckminster users, a component is an Eclipse project, but
| |
| − | components are a larger concept than that - components can be external to
| |
| − | Eclipse, components can have attributes, dependencies, perform actions, etc.</p>
| |
| − | <p>A component is expressed in a Component Specification (CSPEC) "language", which in the most general case is stored in an XML file following the Component Specification XML Schema, inside the component. But as you will see later, for many component types the required information is already available through other means (as an example; Eclipse plug-ins carry a lot of extra data), and in these cases, Buckminster will translate such information on-the-fly and there is no need to repeat what is already known. But more about this later.</p>
| |
| − |
| |
| − | ==Components Do Not Stand Alone: Dependencies==
| |
| − | Components may depend on other components but a fundamental concept in Buckminster is that it's not until you do something with a component that the pre-requisites arise. Depending on what you do, you might need different things. As an example, for a complilation-action of component A you may need interfaces (or headerfiles of some sort) from component B, but you do not need the rest of B, and later, when running the system you may need B in compiled binary loadable library form (but you are not interested in headers or the source of B). Buckminster separates the two concepts - the term dependency denotes the overall dependencies (every dependency), and the term pre-requisite is used to denote that there is some action that has a dependency (what is needed for a particular action).
| |
| − |
| |
| − | So, as an example; when using Buckminster lingo, you say: "A has a dependency on B", what you really are saying is: "There are actions in A that requires B".
| |
| − |
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image8.gif<br>
| |
| − | <i>A component has zero or more dependencies</i></p>
| |
| − | <p>Obviously Buckminster finds the closure of the dependency graph when it
| |
| − | materializes a workspace. The closure will always be in the form of a Directed
| |
| − | Acyclic Graph (DAG). In our pictorial example, component A requires
| |
| − | components B and C, and component B requires component D, and component C
| |
| − | requires component D, so when Buckminster will load all four into the workspace.</p>
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image9.gif</p>
| |
| − |
| |
| − | As you may have figured out, this is a simplification of what is really going on. Actually, some action was invoked on A, triggering the pre-requisites for that action - something is needed from B, and C, and when obtaining those things from B, and C, those actions in turn have pre-requisites on something obtained from D.
| |
| − |
| |
| − | A component's dependencies, actions, and the actions' pre-requisites are all expressed in the Component Specification (CSPEC).
| |
| − | ====Why the separation of dependecy and pre-requisite?====
| |
| − | You may wonder why dependencies are declared separately from pre-requisites in actions. Surely, the dependencies could be figured out by just following the pre-requisites? The reason for separating the two is beacuse there is a lot more to say about the dependency that only applies once - such as which version of a particular component is wanted; specifying this multiple times, once per pre-requisite is not such a good idea as it is easy to make a mistake and include different versions of the same component for different actions.
| |
| − |
| |
| − | ===Versioned Dependencies===
| |
| − | <p>Software has always been a challenging field because, unlike the continuous
| |
| − | (or analog) nature of the real world, software is discrete (or digital). Thus a
| |
| − | feature that worked in version 4.5 of the system may no longer work in version
| |
| − | 5.0 or even in 4.6 or even in 4.5.1. Thus cspec dependencies include a version
| |
| − | matching clause.</p>
| |
| − | <p>There are two pieces of a version match clause:</p>
| |
| − | <ol>
| |
| − | <li>The version string</li>
| |
| − | <li>The version type</li>
| |
| − | </ol>
| |
| − | <p>Normally, the version string would be something simple like "4.5". However,
| |
| − | because Buckminster is designed for and by software developers, and because
| |
| − | software is not developed in a linear fashion, the version string is more
| |
| − | complex (and more useful) than the simple "4.5". Specifically, the version
| |
| − | string can denote a range. The characters '[' and ']' are used to denote an
| |
| − | inclusive range and the characters '(' and ')' will denote an exclusive range.
| |
| − | Here are some examples:</p>
| |
| − | <div align="center">
| |
| − | <table>
| |
| − | <th>Example</th><th> </th><th>Predicate</th>
| |
| − | <tr><td>[1.2.3, 4.5.6)</td><td> </td><td>1.2.3 <= x < 4.5.6</td></tr>
| |
| − | <tr><td>[1.2.3, 4.5.6]</td><td> </td><td>1.2.3 <= x <= 4.5.6</td></tr>
| |
| − | <tr><td>(1.2.3, 4.5.6)</td><td> </td><td>1.2.3 < x < 4.5.6</td></tr>
| |
| − | <tr><td>(1.2.3, 4.5.6]</td><td> </td><td>1.2.3 < x <= 4.5.6</td></tr>
| |
| − | <tr><td>1.2.3</td><td> </td><td>1.2.3 <= x</td></tr>
| |
| − | </table>
| |
| − | </div>
| |
| − | <p align="center"><i>Examples of version ranges.</i></p>
| |
| − | <p>Buckminster is not limited to the major.minor.micro number notation used in
| |
| − | this example. That notation is just one of several possible notations. Each
| |
| − | notation corresponds to a <i>version type</i>. The type interprets the
| |
| − | version token(s) of a range and assings a magnitude to the result so that
| |
| − | versions can be compared. Buckminster allow new types to be added dynamically.</p>
| |
| − |
| |
| − | ===Mapping Versions to a Revision Control System===
| |
| − | <p>The versions used in the dependency specification will often be meaningless
| |
| − | to a revision control system. Buckminster will therefore use a [[Buckminster Version Converter|Version Converter]]. It is the responsibility of the converter to create something that a
| |
| − | revision control system can understand. The converter will also be able to
| |
| − | convert in the other direction and it plays a very important role when the best
| |
| − | match for a version string is to be found in a revision control system. The
| |
| − | version is converted into a [[Buckminster Version Selector|Version Selector]],
| |
| − | a Buckminster data structure describing if the version is a branch, or a tag, if it is based
| |
| − | on a time-stamp or a change-number.
| |
| − |
| |
| − | A combination of two version converters included with Buckminster and their functionality to use regular expressions makes it easy to set up even a quite complicated bi-directional mapping between a repository and a version selector. As an example, a plain version such as <tt>"3.1.0"</tt> can be converted into the version selector <tt>"main/v3_1_0-xyz"</tt> for a tag converter, or the plain version <tt>"3.1.0"</tt> into the version selector <tt>"three_one_zero/LATEST"</tt> for a branch converter. It is required that the mapping can be reversed without loss of information. See [[Buckminster Version Selector|Version Selector]] for more information about the syntax of the data, and [[Buckminster Version Converter|Version Converter]] for information about the two supplied converters.</p>
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image10.gif<br>
| |
| − | <i>Branches and versions of component C that one might find in a revision control system.</i></p>
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image11.gif<br>
| |
| − | <i>Component A depends on the specific<br>
| |
| − | version "main/2.0" of component C</i></p>
| |
| − | <p align="center"></p>
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image12.gif<br>
| |
| − | <i>The component DAG with explicit branch specifiers on each dependency.</i></p>
| |
| − |
| |
| − | ===The Simplest Case of Versions===
| |
| − | <p>The simplest version numbering (branch specifications) is the linear version
| |
| − | numbers: 1.0, 1.1, 1.2, 2.0, etc. Linear version numbers are the base case: a
| |
| − | revision control system with just one main branch.</p>
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image13.gif<br>
| |
| − | <i>Component B has one main branch, the <default> branch.</i></p>
| |
| − | <p>When the component dependencies have no branch specifier, Buckminster uses <tt><default>/LATEST</tt>
| |
| − | which translates to "the latest version of the default branch". The
| |
| − | default branch varies by revision control system: CVS uses "HEAD", SVN
| |
| − | uses "trunk",
| |
| − | ClearCase uses "main", etc.</p>
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image9.gif<br>
| |
| − | <i>Component A's dependency on component B has no branch <br>
| |
| − | specifier, thus Buckminster uses B:<default>/LATEST</i></p>
| |
| − | <p>If the cspec dependency includes a version number, Buckminster uses a <i>version
| |
| − | converter </i>to translate the version number into a branch specification. The
| |
| − | most common translation is "version" into
| |
| − | "<default>/version". For example:</p>
| |
| − | <p align="center">http://www.eclipse.org/buckminster/drafts/images/image14.gif<br>
| |
| − | <i>Component A's dependency on component B is version "2.0"<br>
| |
| − | which gets translated to "<default>/2.0". Similarly, the
| |
| − | dependency<br>
| |
| − | on component C is "1.1" which gets translated as
| |
| − | "<default>/1.1".<br>
| |
| − | Looking at the branching diagram above, we see that "<default>"
| |
| − | is<br>
| |
| − | "main", thus Buckminster will load "main/1.1" to satisfy
| |
| − | that dependency.</i></p>
| |
| − |
| |
| − | ===What If There Isn't a Revision Control System?===
| |
| − | <p>What if the component is not stored in a revision control system? For
| |
| − | example, what if the component is stored in an FTP directory? The answer is that
| |
| − | the <i>providers </i>and <i>component readers </i>defined in the rmap handle
| |
| − | reading versioned components from the appropriate repository. If the repository
| |
| − | does not provide versions, then the component reader treats the repository as if
| |
| − | it has just one version: <tt><default>/LATEST</tt>. Requesting any other
| |
| − | branch specification will fail.</p>
| |
| − | <p>Or, to put the situation more positively, Buckminster treats a "no
| |
| − | revision control system" situation as a simple revision control system that
| |
| − | provides only one branch and one version.</p>
| |
| − |
| |
| − | ===The Flexible Case of Versions===
| |
| − | By using a different version converter, Buckminster can map versions to change numbers, timestamps, or branches instead of tags. We expect the most typical configurations to be based on tags (something stable), or the latest on the main/default branch, or the latest on a particular branch. Combinations can sometimes make sense, but this also depends on the particular repository being used, and how content has been organized, tags set etc.
| |
| − |
| |
| − | Checkout [[Version Converter (Buckminster)|Version Converter]] for more information.
| |
| − |
| |
| − | == Component Attributes with Pre-requisites ==
| |
| − | Remember we said that pre-requisites are declared when a component needs something from another component to perform an action. It is time to look into how this works in more detail. What has been said up to this point has been a slight simplification.
| |
| − |
| |
| − | Let's start with an example:
| |
| − | We know that in order to compile component A, we need access to the header files/interfaces provided by component B. To declare this we add a compile action to component A's CSPEC, and add a pre-requisite of component B's "headers" to this action. In component B we need to declare the corresponding "headers" so it represents the set of needed headerfiles.
| |
| − |
| |
| − | How is this done?
| |
| − | <p align="center">[[Image:Bmareq1.jpg]]</p>
| |
| − | <p align="center"><i>A compile action in A has a prerequisite on headers in B.</i></p>
| |
| − | A component has attributes of the type <i>Artifact Group</i>. Such an attribute can either be data directly, or trigger an action producing the data. An Artifact Group, as you may have guessed represents a structure of files (one file, a flat list, multiple lists, a tree, a multi rooted tree etc.) An attribute has a name that is unique within a component. A pre-requisites simply refers to an attribute in a component.
| |
| − |
| |
| − | ===How are attributes specified?===
| |
| − | A component attribute in Buckminster sort of works as a getter method (using Java/OO terminology), and this is implemented by using one of the clauses <tt>artifact</tt>, <tt>group</tt>, or <tt>action</tt>. An <tt>artifact</tt> specifies none, one, or several paths to either individual files or directories (denoted by a path ending with a slash (/)). A <tt>group</tt> specifies a list of other attributes (which in turn may be artifacts, actions, or groups (recursively)). Finally, <tt>action</tt>, that can produce a path structure on-the-fly returned as the value of the attribute.
| |
| − |
| |
| − | So, in our example, component B has an attribute called "headers" that is an artifact element with the path to the directory with headers.
| |
| − |
| |
| − | ===Local and External Pre-requisites===
| |
| − | When an attribute has a pre-requisite on another attribute in the same component, it is said to be ''local''. When the pre-requisites needs to reference an attibute in another component it is said to be ''external''. The external reference uses component name, and attribute name.
| |
| − |
| |
| − | ===Private and Public Attributes===
| |
| − | Attributes can be private or public. The private attributes can only be used as pre-requisistes for attributes in the same component. This makes it possible to create common datasets (artifacts, and groups), or actions that are shared internally by the public attributes in the component. You do not have to repeat identical sequences and thus save time, space, and creates a more robust, easier maintainable specification.
| |
| − | <p align=center>[[Image:BMprivateAction.gif]]<br>
| |
| − | <i>the headers attribute has a local private pre-requisite that headers are generated using an action</i></p><br>
| |
| − |
| |
| − | The most valueable use for private attributes is probably to hide internal complexities from users of the components. The user does not have to understand how certain sets of files are produced. Maybe the header files are generated from a UML model - the user should not need to know that.
| |
| − |
| |
| − | ===Attributes that are Components===
| |
| − | Sometimes, an entire component is created as the result of some action in another component. Buckminster handles this by allowing a "obtained from" statement in the dependency declaration. As an example if component A depends on component X, and component X is obtained by getting attribute X in component B. Then, the declaration in component A states the dependency on "component X obtained from component B's attribute X". The dependency on component B must also be specified.
| |
| − |
| |
| − | With this construct in place, it is possible to have pre-requisites on attributes in the component X.
| |
| − |
| |
| − | ==Abstract Components==
| |
| − | Although not likely to be fully implemented in Buckminster version 1.0, it is of value to understand this simple but yet powerful concept.
| |
| − |
| |
| − | A dependency on an Abstract Component means that there is a dependency on a component that is a concrete realization of the abstraction. For example, a component may require that there is a SQL database available in order to run the component. In this case, the component can declare a dependency on the Abstract Component "SQL". When components like "MySQL", "PostgreSQL", and "Oracle" are declared to be concrete realizations of the "SQL" component a component query can fulfill a request (or show available options).
| |
| − |
| |
| − | ==Dynamic CSPECs and extensions==
| |
| − | Buckminster is capable of handling components expressed in different "component languages". One such language is the [[Buckminster Component Specification]] CSPEC, a language capable of capturing if not in the current version all, a majority of the component languages in use. The CSPEC can be thought of as the Rosetta Stone or Lingua France of Component meta data if you like.
| |
| − |
| |
| − | ===What other component languages are supported?===
| |
| − | When this introduction is written there are translators (In Buckminster terms, [[Buckminster Component Type|Component Types]]) that can read component meta data and translate to CSPEC format on-the-fly for Eclipse PDE, and Maven. A [[Buckminster Component Reader|Component Reader]] is also involved as it is responsible for the protocol used to get to the component data. Buckminster is extendable to handle other component meta data languages.
| |
| − |
| |
| − | ===How does it work?===
| |
| − | When a component already has meta data (e.g. Maven or Eclipse PDE), this metadata is read and translated into a CSPEC that resides in the project model (i.e. in memory). It is possible to write this generated CSPEC to an XML file for viewing or other purposes.
| |
| − | By generating the CSPEC on the fly, there is no need to maintain the same meta data in more than one place - the natural place; in the original component where the data is required anyway.
| |
| − | <p align="center" style="margin:40px;">[[Image:Generated-cspec.gif]]<br>
| |
| − | <i>ComponentReader and ComponentType cooperate to read component meta data and translates it<br>into an in-memory CSPEC used by Buckminster. The in-memory CSPEC can also be viewed or exported to a CSPEC file in XML format.</i></p>
| |
| − |
| |
| − | Sometimes, however, the meta data in the component itself is not enough. This could be because the component meta data language does not have the expressive power to handle certain things that are important when materializing and performing component actions (compiling/building/packaging/installing/copying/encrypting or whatever). In these cases, Buckminster provides an extension mechanism to the CSPEC, called CSPECX.
| |
| − | <p align="center" style="margin:40px;">[[Image:CSPECXtension.gif]]<br>
| |
| − | <i>The CSPECX extends the generated CSPEC with overrides and additions.<br>The result is used by Buckminster.</i></p>
| |
| − |
| |
| − | The CSPECX, is stored in a file in the component (with the extension .cspecx), it is in the same format as the CSPEC in general, but here it is also possible to override the generated specification.
| |
| − |
| |
| − | ==Bill of Materials==
| |
| − | When Buckinster has finished the resolution of a configuration (i.e. when Buckminster has followed all pre-requisets for an action, finding the correct version of other components via the stated dependencies) a Bill of Materials (BOM) is created. The BOM describes all the components and the version of each component included in the configuration (for full traceability, it also includes the Component Query that was used to produce the BOM). The materialization takes the BOM as input and materializes the required components (i.e. makes them available to the project).
| |
| − |
| |
| − | Currently, the BOM can not be exported, it is kept in Buckminster's model. You can expect functionality to be added at some point that both allows you to export the BOM to an XML file, and to materialize from such an externalized BOM.
| |
| − |
| |
| − | ====Variability and 'open/closed' BOMs====
| |
| − | A concept that is not likely to be included in Buckminster 1.0 is support for variability. Variability means that the BOM is not fully resolved - there are still things that needs to be specified to make things work. This functionality goes hand in hand with Abstract Components where as an example a BOM may still hold open which database engine to use in runtime.
| |
| − | The Buckminster terminology for this is that an "open BOM" is not completely resolved, and a "closed BOM" is.
| |
| − |
| |
| − | ===The BOM is read only===
| |
| − | The BOM is always read-only. Even if the BOM would happen to be "open" the resolution of the open dependencies results in a new BOM (that is less open, but not necessarily closed, thus allowing further variability).
| |
| − |
| |
| − | As an example, you are perhaps creating a product that can be used with various different "3d party" components in runtime; different databases, different application servers, message queues, etc. Producing pre-built/configured packagings of all combinations is a major shore and often leads to overly bloated software distributions that includes everything (and the kitchen sink).
| |
| − |
| |
| − | The idea here is that you instead ship the pieces and let Buckminster resolve the remaining dependencies as part of an "installation"
| |
| − |
| |
| − | ==Component Query==
| |
| − | A [[Buckminster Component Query|Component Query]] (CQUERY) is the topmost input to the Buckminster materialization process. It specifies "the thing you want materialized" and provides guidelines for the resolve and materialization stages of the process.
| |
| − |
| |
| − | A CQUERY is created using the forms based CQUERY editor, or by editing an XML file. The CQUERY contins things like the name of the top most component, and the wanted version (or range of version), as well as many other parameters that control the materialization - which [[Buckminster Resource Map|RMAP]] to use, if you want to skip certain components, if you want to trust local copies (perhaps materialized previously), if you want to override certain settings, etc.
| |
| − |
| |
| − | Once you are done editing the query, you can save it and reuse it. It is also ideal to share with other members of a team (together with the RMAP). They can then easily re-create the same setup as you have created.
| |
| − |
| |
| − | ===Sharing a CQUERY and RMAP===
| |
| − | Once you have created a suitable CQUERY and RMAP, you make them available to your team (or the public) by making the files available on a web site (actually, via URLs). Make sure the CQUERY contains the RMAP URL. Tell people to start Eclipse, use the ''Open File ...'' dialogue and simply type (copy/paste) the CQUERY URL into the ''Filename field'', and then click ''Open''.
| |
| − | That will open the CQUERY editor, from which the configuration can be materialized.
| |
| − | <p align="center" style="margin:50px;">[[Image:CQUERYScenario.gif]]<br>
| |
| − | <i>Eclipse materializes from a published CQUERY and RMAP</i></p>
| |
| − |
| |
| − | == MORE MORE! ==
| |
