*<b>[[#Tight integration with Eclipse PDE-build|Tight integration with Eclipse PDE-build]]</b> - Buckminster is now able to build the

+

*<b>[[#Tight integration with Eclipse PDE-build|Tight integration with Eclipse PDE-build]]</b> - Buckminster is now able to build the org.eclipse.rcp feature from source using releng specific map files.

* <b>[[#New meta-data storage implementation|New meta-data storage implementation]]</b> - 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.

* <b>[[#New meta-data storage implementation|New meta-data storage implementation]]</b> - 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.

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.

Headless boot simplified

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.

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'.

Syntax Changes

Prerequisites for groups and actions was previously written like this:
<local attribute="aLocalAttr"/>
<external attribute="anExternaAttr" component="X"/>

These are now 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.