Difference between revisions of "Spaces Project Setup (Buckminster)"
|Line 34:||Line 34:|
Revision as of 23:29, 14 February 2009
How to materialize and build
The actual process of bringing the code into your workspace and build it is explained on the Spaces/Building from source wiki page.
Since the project is built from features and plug-ins, Buckminster will extract most of the information that it needs from the meta-data normally present in such projects and there are only a few additional artifacts needed.
The Component Query
In order to materialize the project into a workspace, Buckminster needs a component query CQUERY (Component Query). The query is designed so that it will ask for the Spaces top component org.eclipse.spaces.update. A transitive resolution of the dependencies that extend from this component will automatically bring all other components into the Bill Of Materials (BOM) that Buckminster creates.
The query is published on the Spaces web. You can view it here. The only things specified in this query besides the name of the top component are:
- The top component type. In this case buckminster. This tells the resolver to look for a component that contains a manually added Buckminster CSPEC (Component Specification).
- An advisor node that matches all components with a name that starts with org.eclipse.spaces. This node specifies a resolution scope that excludes the target platform. The reason for this is that is that you will want the projects materialized into our workspace even if they are also installed in your IDE. If this node wasn't there, and if the IDE has spaces installed, the resolution would be very quick and the workspace would still be empty after the materialization.
- A URL pointing to the Buckminster RMAP (Resource Map). When the query is resolved, it will be resolved using the resources declared in this map.
The Resource Map
The resource map is also published on the Spaces web. You can view it here. It will trap all requests for components with names starting with org.eclipse.spaces and resolve them using a searchPath that contains a provider using a svn readerType. This provider is configured so that it finds all the spaces sub-projects present under the org.eclipse.spaces SVN root.
All other component requests are redirected to this RMAP. This is what Buckminster uses for dogfooding and the Spaces project is reusing some of the Buckminster plug-ins.
The top-component, org.eclipse.spaces.update is the only one that contains a manually added cspec. If you are familiar with the Ganymede site contribution files, you will see that this CSPEC has a lot in common with a site contribution. This is where all the features are listed as dependencies and also where they are grouped into what will become categories on the Update Site (Spaces doesn't have any categories just yet though).
In addition to the dependencies and optional category groups, this cspec also contains an action that will build the actual update site.