Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [buckminster-dev] Relative URI for local readerType in provider search path

What I generally do in a buckminster build is have a dual-resolution
approach in the rmap by putting two providers in the searchPath
element. Here's an example from

http://dev.eclipse.org/svnroot/stp/org.eclipse.stp.build/build/trunk/stp/

The 'local' provider does the resolution for the disk - you'll see that the
URI format uses a ${project.root} buckminster property expansion to
indicate the base directory where the code to be discovered resides.

-----example-----
    <searchPath name="sca.features">
       <provider readerType="local"
componentTypes="eclipse.feature,osgi.bundle" mutable="true"
source="false">
          <uri format="{0}/org.eclipse.stp.sca/features/{1}">
              <bc:propertyRef key="project.root" />  <!-- THIS IS IT -->
              <bc:propertyRef key="buckminster.component" />
          </uri>
       </provider>
       <provider readerType="svn"
componentTypes="osgi.bundle,eclipse.feature,buckminster"
mutable="true" source="true">
          <uri format="http://dev.eclipse.org/svnroot/stp/org.eclipse.stp.sca-tools/org.eclipse.stp.sca/trunk/features/{0}";>
              <bc:propertyRef key="buckminster.component" />
          </uri>
       </provider>
    </searchPath>

-----end example-----

So, the next question might be - how do I get that value 'into' the build?
When starting up buckminster you need to give the launching JVM values for
any properties that are addressed from within the buckminster artifacts. In the
STP build [0] I use Apache Ant to kick things off. I make an Ant macro which
declares a <buckminster> Ant task [1] that I use later on (effectively this is
copied  from Buckminster's own build :) There are a couple of magic moments
that are to be explained at this point.

1. You want to provide ${project.root} as a path, e.g. "../..". Buckminster
doesn't like that - it wants a URL. So the magic <makeurl> task does
this transform.

<makeurl file="${project.root}" property="project.root.url" validate="false"/>

The URL to feed to Buckminster is now in ${project.root.url}. I don't validate
the URL because that would spew if the file did not exist. Remember I want
to check for local disk presence and if not found fallback to checking it out
from source. So 'not found' is a valid result for me in my use-case.

2. The value of the property is passed as a JVM argument to invoking
Buckminster

<java fork="true" jar="${buckminster.launcher.jar}" failonerror="true">
...
   <jvmarg value="-Dproject.root=${project.root.url}"/>
...
</java>

Note the name change here - ${project.root} is what the rmap seeks.

Another thing worth noting if you haven't spotted this already is that your
cquery will natively take a relative path for locating your rmap like so:

<componentQuery xmlns="http://www.eclipse.org/buckminster/CQuery-1.0";
                            resourceMap="stp.rmap">

Feel free to go in and help yourself to chunks of build from the STP
project - a simple example would be [2] - just svn co <that URL> -
it will pull in some svn externals - and you can explore a bit.

cheers
  --oh

[0] http://dev.eclipse.org/svnroot/stp/org.eclipse.stp.build/build/trunk
[1] http://dev.eclipse.org/svnroot/stp/org.eclipse.stp.build/build/trunk/buckminster/buckminster.xml
[2] http://dev.eclipse.org/svnroot/stp/org.eclipse.stp.policy-editor/org.eclipse.stp.policy/trunk/build


Back to the top