Ecf.rmap

Return to Building ECF Release 3.2

For a Buckminster build, the first thing to set up is an rmap. ecf.rmap is the rmap file that we use with the ECF SDK.

Now it works just fine, but I think there is extraneous information in it. It would be good to know exactly what is needed and what is not.

• Search path (org.eclipse) has providers (eclipse.import, PDEMapProvider). This is where we get the eclipse plugins that come with the platform. Why do we need PDEMapProvider here?
• Search path (org.eclipse.emf) has providers (eclipse.import, PDEMapProvider). Why do we need this? Why do we need PDEMapProvider here?
• Search path (org.eclipse.ecf) has provider (local). This is where we get the ECF code.
• Search path (org.pluginbuilder) has provider (eclipse.import). This is not currently used.
• Search path (org.eclipse.swtbot) has provider ( (eclipse.import). Is this used? Is this for testing purposes, which are not yet doing.
• Search path (default) has providers (eclipse.import, PDEMapProvider). This is where we get the stuff from Orbit. Why do we need PDEMapProvider here?

Without a resource map, Buckminster can only find resources in the Eclipse IDE.

What does an rmap do? It defines searchpaths, providers and locators. The locators appear at the end of the file, but they really are the first things used. When Buckminster looks for a component, it goes through the locators in the order in which they are defined. Go to locators to see how the locators are defined.

Here is an example of a locator. The locator matches a pattern. What this locator does is get everything in org.eclipse.ecf. The pattern ^org\.eclipse\.ecf(\..+) is explained on page 29 of the Bucky Book.

<locator searchPathRef="org.eclipse.ecf" pattern="^org\.eclipse\.ecf(\..+)?" />

The text in the Bucky Book is “start with a ^ which means that the matching is anchored at the start of the input (and the input in this case is a component name). ” and then further, “At the end of the second pattern you see (\..+)? which means zero or more occurrences of a literal period followed by a sequence of one or more characters. This is a good pattern to use when projects (i.e. component containers) are named after the component names and period is the only separator used.”

I don't know what “anchored at the start of the input” means. </-> <p> So what happens after a match. Well, the match identifies a searchpath. In the case of the example above that searchpath is org.eclipse.ecf. And the searchpath provides a provider which has three pieces of information: a reader type how to read the content of the repository), a component type (how to interpret that content), and where to go to get the actual content.

Note that you can have more than one provider per searchpath. So which one gets used? A provider gets a score based on how well it matches. Bucky uses the provider with the highest score and if two providers have the same score, Bucky uses the provider that's listed first. (page 31).

Also note that our build machine is ecf2.osuosl.org, which is a mirror for eclipse downloads. Hence we can use rsync to identify the actuasl location in <uri/>.

The ECF code that we build mostly comes from the search path (org.eclipse.ecf) and the provider (local).

“The local reader is used in situations when the material you are interested in already exists in the file system in the form you want. In this case, Buckminster does not materialize anything (i.e. no downloads or copying takes place ... Instead, Buckminster simply reads the meta data available in the appointed location and binds the location into the workspace as a project.” (Bucky Book, page 38).

Look at the definition of the local provider.

<uri format="file:{0}/{1}/">
<bc:propertyRef key="projectsPath" />
<bc:propertyRef key="buckminster.component" />

The path is <value of projectsPath>/<value of buckminster.component>. The value of projectsPath comes from the Hudson configuration of the Buckminster step Advanced Options, -DprojectsPath=${WORKSPACE}/projects.

Here's the latest version of the ecf.rmap file.