[buckminster-dev] Re: Buckminster - a lot of questions

[Thomas Hallgren <thomas@xxxxxxx>]

Hi Ted,
I'm pleased to hear that you are interested in Buckminster and that you've made it through
our demo. Here's an attempt to answer your questions. I hope there will be more coming.

> 1)... I have no clue how Buckminster found the dogfood component
> specification.  I just typed 'org.eclipse.buckminster' into the
> Buckminster Open Project wizard and Buckminster did its thing.  How did
> Buckminster know where to look for the 'org.eclipse.buckminster'
> component specification XML?
>
When a component is materialized, it's a four step process.
1. Find providers for all components and resolve dependencies transitively.
2. Let the providers materialize the components (make them available locally).
3. Bind the components to your Eclipse workspace.
4. Perform the initial "assembly build" step.

At the first stage, Buckminster will construct a 'component request'. In its simplest form,
the request is merely a component name. It can be attributed with version selector,
match-rule, and a version comparator type (knows how to interpret the version selector).
This request is passed to the Buckminster resolver. The resolver will utilize a 'Resource
Map' where the component name is mapped to a 'searchPath' using a regular expression.

The searchPath in turn, contains a sequence of providers and a provider combines a reader
type (such as cvs, svn, maven, etc.), with a component type (eclipse-project, maven) In
essence, the readerType knows *how* to read, the component type knows *what* to read and how
to convert the information into a Buckminster dependency graph. A provider also has a url
and a versionConverter. The url is provider specific and tells the reader what it needs to
know to make the connection and find branches, tags, etc. The versionConverter converts
versions into tags, branches, or combinations thereof. A version 1.3.5 is perhaps converted
into a cvs-tag v1_3_5 etc.

At present, Buckminster contains a default resource map. If you have the source handy, you
will find it in the buckminster.core component as
'src/java/org/eclipse/buckminster/internal/default.rmap' but I also include it below for
reference.

The default resource map essentially maps all buckminster entries to the cvs repository or
to www.ibiblio.org where we pick log4j and the tada-sax utilities. I sad, "at present"
because a default resource map only benefits buckminster developers (and at present, the
dogfood demo). In our next iteration, the default resource map will be removed, and a
dogfood.rmap will be made available instead for demo pupropses.


> 2)... We use SVN.  We tag plugin versions in the usual SVN way...by
> copying the associated plugin project folder under the SVN trunk folder
> to a folder under the SVN tags folder.  To create a particular build of
> a product we must assemble a workspace by hand by checking particular
> versions of plugin projects out of SVN from the correct tag folder (all
> based on the feature definition for the client).
>
> Does (or will) Buckminster have a standard SVN retrieval mechanism that
> will work with SVN out of the box?
>
Yes. Buckminster has a Subversion plugin that is built on top of the standard Subclipse
plugin from tigris.org.

> If so then is there a particular convention that will need to be
> followed to work with SVN (like a particular folder naming convention)?
>
Well, yes and no. At present we require that the standard names are used, i.e. tags,
branches, and trunk. But we're still quite flexible in how components can be organized below
or above this structure. The following is from the Javadoc of the SvnRemoteFileReader.

/**
 * The SVN repository reader assumes that any repository contains the three
 * recommended directories <code>trunk</code>, <code>tags</code>, and
 * <code>branches</code>. A missing <code>tags</code> directory is
 * interpreted as no <code>tags</code>. A missing <code>branches</code>
 * directory is interpreted as no branches. The URL used as the repository
 * identifier must contain the path element trunk. Anything that follows the
 * <code>trunk</code> element in the path will be considered a
 * <code>module</code> path. The repository URL may also contain a query part
 * that in turn may have four different flags:
 * <dl>
 * <dt>moduleBeforeTag</dt>
 * <dd>When resolving a tag, put the module name between the <code>tags</code>
 * directory and the actual tag</dd>
 * <dt>moduleAfterTag</dt>
 * <dd>When resolving a tag, append the module name after the actual tag</dd>
 * <dt>moduleBeforeBranch</dt>
 * <dd>When resolving a branch, put the module name between the
 * <code>branches</code> directory and the actual branch</dd>
 * <dt>moduleAfterBranch</dt>
 * <dd>When resolving a branch, append the module name after the actual branch</dd>
 * </dl>
 * A fragment in the repository URL will be treated as a sub-module. It will be
 * appended at the end of the resolved URL.
 *
 * @author Thomas Hallgren
 */

Needless to say, if you have other ideas and/or requirements that would make the SVN reader
more useful, then we are very interested in hearing about them. We want to solve real-life
problems with Buckminster and not impose a structure that we invent ourselves.

>
> -----------------------
> some background if you care to read this far...
>
> I am the lead tech for a company that produces a business system that is
> build on top of Eclipse.
> Our product is entirely plugin-based.  We customize our product by
> creating custom plugins for each of our clients and we also encapsulate
> new features and functions into thier own plugins.  We also produce many
> updates to our core product.
>
> We desparately need something like Buckminster to manage/materialize
> builds for all our clients.
> Our build process is currently PDE driven, that is, driven entirely by
> features.  We create a unique feature definition for each of our
> clients.  So, for any client we basically know the exact collection of
> plugins, and what versions of those plugins, go into a particular
> client's build.
> However, its a real pain-in-the-butt to build a particular version of a
> product for a particular client - and the process is also very error
> prone.  Also, tagging plugins with version tags is a big hassle (we use
> SVN).
>
You sound like the ideal customer :-)
More then that actually. It sounds like you could help us shape Buckminster into something
even more useful. We are very open to new ideas and any help we can get is greatly appreciated.

A new milestone, M2 will soon be released. With it, we introduce a new concept that we call 
component query. Such a query combines a component request with a lot of 'advice nodes' that 
 answers questions that might arrive during the transitive dependency resolvement and 
materialization process. Typically you can define different strategies to what should happen 
when Buckminster finds old materializations, when it finds plugins in your Eclipse 
installation that might be used, etc. My hope is that we will have this milestone ready by 
the end of this month.

Kind regards,
Thomas Hallgren