Installation and configuration (Buckminster)
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 10% of the IDE installation side (or even more by hand pruning the result).
Buckminster Alternate Packagng
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. 4 MB (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.
Customizing the product
Roughly, there are four things you need to do to customize a product for your team, say:
- Download the raw product
- Initialize it
- Configure it
- Pack it up/deploy it
The object in step 4 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 raw 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 raw 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.
A difference from an Eclipse IDE installation is that there are technical reasons making it difficult to correctly include a 'buckminster' binary in the top level directory. Thus, there is a separate step that has to be run the very first time (obviously, this is later intended to be hidden behind a more traditional 'install' procedure if necessary).
Thus, you must first run the following command:
Assuming there are no other problems, this will typically open a new shell window and report how and where to set your path etc, and a note on 'INITIALIZE OK'. Just press Enter to dismiss the window. You should now have the necessary buckminster binaries placed as they should.
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. [[Sample product configuration (Buckminster)|Here] is a sample showing how I configure a Buckminster product with higher order Buckminster features and required Eclipse features.
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).