1.0.0.v20061213 Release Notes (Buckminster)

< To: Buckminster Project

What has changed in this build?

• Tight integration with Eclipse PDE-build - Buckminster is now able to build the org.eclipse.rcp feature from source using releng specific map files.
• Headless boot simplified - Headless Buckminster is now much smaller in size, dependency on binary launcher removed, initialization cleaned up, and options now conform to standard Eclipse options.
• New meta-data storage implementation - the previous implementation was sensitive to changes taking place without Buckminster's knowledge. Meta-data storage is now reimplemented and should be much more stable.
• XML-Schema cleanup - The Buckminster XML-Schemas have been modified; some syntax has been deprecated and replaced with newer constructs, and the number of schema files have been reduced.
• Some internal restructuring in the Buckminster plugins; feature naming is now more consistent.

What you need to do

• Uninstall any previous build of the buckminster plugins (either by using the update manager uninstall command), or by removing the buckminster plugins under the Eclipse install directory.
• Reinstall the Buckminster plugins using "Find and Install" - As described in Getting started with Buckminster.
• If you have written plugins that extend the Buckminster plugins you need to upgrade these extensions. Take a look at the changes in the examples used as starting point. If you run into problems please contact the Buckminster team on the mailinglist/newsgroup. We can schedule a conference call on request to help out.

Headless boot simplified

Background

Previously, a special installation was necessary for the headless product where a '_productInitializer initialize' command copied a special version of the Eclipse startup.jar and a special binary launcher into the root location. The launcher was tailor made for headless execution and managed exit codes the correct way. It started the special version of the startup.jar that parsed initial options before it called on the Eclipse startup.jar. This so that we could have our own global options.

The drawbacks of that approach was that:

• We needed different binary compilation of the launcher on different platforms.
• We had our own version of some Eclipse specific options (-W for workspace instead of the commonly used -data in particular) and we provided no support for many others.
• Since the decision on what JVM to use was made in our version of startup.jar, a boot sometimes required two different JVM invocations.
• The size of our product was bigger then it needed to be.

Solution

The new product relies completely on the Eclipse normal startup.jar and uses a shell-script (.bat in case of Windows) to start it. The script knows only how to launch the selected JVM with correct JVM parameters. The rest is passed on to the startup.jar. This means that:

• No special _productInitializer is needed (and none is present)
• No binary launcher is needed (nor present)
• We use standard Eclipse global options.
• The product size shrunk from ~10MB to 2MB.

The product consist of three plugins:

• org.eclipse.buckminster.runtime

  Basic runtime support (Logger, some Preferences, URL, and IO support functions). We no longer use the log4j logger. Instead we integrate with the Eclipse internal log facilities. We thereby decrease the size, the number of dependencies, and make life less complicated for the end user.

• org.eclipse.buckminster.cmdline

  The command line framework that provides the extension point needed to add new commands.

• org.eclipse.buckminster.installer

  The installer that interacts with the Eclipse Update Manger and thus makes it possible for the product to extend itself.

Since the product is meant to sometimes extend itself and be used in various runtime scenarios it doesn't contain any Java 5 specific code.

New meta-data storage implementation

Background

When we started with Buckminster, we kept some meta-data around. The definition of that data was not carved in stone and as it grew, we didn't do a good job of separating immutable data from data that was supposed to move when the data in the workspace changed. We've long had plans to rectify this and at the same time bring in a database of some sort (something like derby). As it turned out, there was some issues since derby defines one central point of management per JVM. Problematic since we don't know what other plugins that might use Derby and since Derby themselves do not define a plugin that is made to fit that purpose. We've told them that it would be great if they could provide that.

Solution

Instead of using Derby, a new meta-data storage was invented where XML images are stored using filenames generated from their MD5 signature. Needless to say, all entities in that storage are completely immutable. That however, suites us very well. We create new entries when things change while keeping old BillOfMaterials completely intact.

All in all, the current meta-data storage works well and is much more resilient to changes made outside of our control.

When rewriting the meta-data we also enforced a much better separation of concern between the resolution and the materialization phase.

XML-Schema cleanup

Background

We started out with the idea that each top element in an XML document should have its own XML-Schema. We ended up with schemas for providers, cspec extensions, etc. and that was somewhat unnecessary. A schema merge was therefor needed.

At the same time we also wanted to modify some syntax to make concepts clearer. After some discussions we decided to use the element name 'attributes' for what was previously called 'groups', 'artifacts' and 'actions'.

Solution

Schemas

In this build, these are the schemas to use:

• Common-1.0

  Definitions common to all other schemas

• CQuery-1.0

  The Component Query and its advisor nodes

• CSpec-1.0

  The Component Specification

• MetaData-1.0

  All meta-data goes here, i.e. BillOfMaterials, Resolution, ResolutionNode

• RMap-1.0

  The resource map

Syntax Changes

Prerequisites for groups and actions was previously written like this:

<!-- Deprecated style -->
<local attribute="aLocalAttr"/>
<external attribute="anExternaAttr" component="X"/>

These should now be written like this:

<attribute name="aLocalAttr"/>
<attribute name="anExternalAttr" component="X"/>

The old style has been deprecated, eventually you must change existing CSPEC files to use this new syntax. In this build you will get deprecation warnings for any declarations that use the old style. Deprecation warnings will be removed in some later build, and you will then instead get hard errors.

Tight integration with Eclipse PDE-build

Using PDE build script generators

Buckminster is now reusing much more of the PDE build functionality. In particular, we make use of the script generators when exporting plugins and features.

Provider for releng specific map files

A new provider was added that makes use of the releng specific map files used by the Eclipse internal build system. The provider will dispatch all requests using map files in an appointed map-directory. These entries will redefine what reader type that is used and the location to use for that reader type. In short, the original reader type and location is used when finding the map-files, the map-files in turn decide the real reader type and location.

Using this provider, Buckminster is now able to build the org.eclipse.rcp feature from source.