Contents

When the full IDE configuration is not needed

There may be occasions where a full Eclipse IDE installation is deemed overkill or just plain is too big (the various features incorporated in the IDE download sometimes contain a lot more than is actually needed). In such cases it would be attractive with something minimal, which can be configured exactly as needed by a workgroup and contain no more and no less than what is required. In the best case this can bring down the size required to less than 2% of the IDE installation size.

Buckminster Alternate Packaging

To accomplish this, Buckminster has an alternate packaging mechanism using the technique of creating an 'Eclipse product', i.e. using parts of the regular Eclipse framework to create a freestanding application that in no way resembles the IDE. So, only a few Eclipse plugins is in there, and just the core of Buckminster. Currently it weighs in at approx. 2MB (compared to a full IDE download at approx. 110 MB). The cost, of course, is that the Buckminster product is mostly unusable by itself. However, it does contain enough to allow it to use the Update Manager mechanisms to install in itself the requisite features. So by just pointing it at relevant update site locations, it can become more powerful. Actually, in principle it should be possible to upgrade it sufficiently to become the IDE...

The product only contains the Headless aspect of Buckminster and is the same as what is possible to install in the IDE, so any documentation are the same. The main difference for the product is that it needs to be customized to adapt to your situation.

Note: You need to download headless as a separate product from the Buckminster download site to use the headless functionality as intended. Just installing the headless features in your IDE does not give you a headless version. In that case you would have the headless things in your IDE but it has a user interface - the very thing we did not want. So, you need the separate product that does not have a graphical user interface.

Customizing the product

Roughly, there are three things you need to do to customize a product for your team, say:

Download the product

Configure it

Pack it up/deploy it

The object in step 3 is to produce a zip package that can be downloaded by team members and just be unpacked to be 'ready to go'. An alternative would be to deploy it to a network location, again 'ready to go'.

Downloading the product

Similar to downloading a full Eclipse IDE packaging, getting the Buckminster product is similar - download a zip archive and unpack it somewhere convenient. See here for a location.

Normally, the product will be stored in a top level directory called 'buckminster'. So for the rest of the text, let's assume that you have unpacked it to 'c:\buckminster' on a Windows platform (again, it should work similarly on a Unix/Linux platform). You can add the directory to the PATH, but here I will assume that you work in the root of the 'buckminster' directory.

Configure it

Configuring your product essentially consists of installing the proper features/plugins into it. This can be accomplished by using the commands associated with the update manager mechanism: install/uninstall/listsite. Here is a sample showing how I configure a Buckminster product with higher order Buckminster features and required Eclipse features.

Note:
Working with this is helped by some knowledge of how Eclipse works - particularly if you get into problems, for example having unfulfilled dependencies. An important tool in these cases can be the command 'dumpinfo' which will give an insight into what features/plugins are installed/recognized/running etc.

In case of problems: either look for a log file in the <workspace>/.metadata directory or in the products 'configuration' directory. Especially disconcerting can be the fact that some problems can result in an invocation of buckminster...and nothing seems to happen (the command prompt just returns). Typically, the Eclipse core framework has then logged an error in a configuration log. A common occurrence is an unfulfilled dependency.

Unfortunately, many features makes the product bloat quite a lot due to their not being enough fine-grained. And, there is no API way of deploying just plugins at this point. An advanced technique is to further prune this size by manually removing plugins not needed. Obviously, this can be a trial and error progress if you are removing plugins somewhat blindly and as noted above you may need to be aware of where to look for clues. Only recommended if you really know what you are doing.

Pack it up/deploy it

Once you are done and feel your product customization is complete, a typical action is to zip it up. Anyone can then just unzip it in a convenient location and start using it - it is completely self-relocating thanks to the Eclipse/OSGi infrastructure (just like the IDE).