Buckminster currently consists of two major implementation parts on paper, AM and CCB. However, CCB is non-existent at this time. It will depend heavily on formats and procedures in AM.
AM, however is implemented and has been in use for quite some time (first and second generation), so it is very stable and functional. As part of moving to an open source model, it is currently undergoing extensive rework however. The reason for this is that it was originally built and designed with a set of requirements that to a large extent are no longer applicable and can thus be removed. In many cases this leads to making it simpler and more easy to use, and also makes AM more tightly focused on the features that are deemed essential. Also, there are some new requirements that are important to address. Thus, this means that until the rework is completed, backward compatibility may be sacrificed.
So to reflect this, AM is periodically released and made available for download (i.e. in the simplest form, the command line 'amtool' configuration), initially as time stamped builds, but soon followed with releases according to a more common release taxonomy, i.e. a three-part major.minor.bugfix numbering scheme.
In all cases, amtool is intended that the last available release will build the HEAD version of amtool itself.
The amtool client builds and works on Win32 and Unix (tested on Linux at the present time), and should behave effectively identical on either platform. But note that the build itself is actually platform/capability sensitive - for example, Linux can't create the Windows executable front end, and only Windows machines with the ActiveState PDK installed can generate 'true' executables, others will create a 'shim' executable.
Two major additions are intended for this period:
AM will support and execute nested configurations which may of an arbitrary depth. For instance where configuration A references another configuration B, and configuration B is expected to produce a component 1 then used by components in A. This way A can include either a prebuilt state of 1 or the entire cfg used to build 1, which can be necessary in bug-hunting scenarios.
Expected impact: Enhanced cfgspec file format. Totally revamped single new format for what today are two formats for workspace/configuration in workspace. Somewhat revamped directory organization in workspace.
A plug-in to enable conveniently connecting the Eclipse IDE to an AM workspace for editing code. This will be relatively simplistic.
Expected impact: enhanced cdl format.
Aside from this, various minor features will be added and fixed made, depending on resource availability. At a minimum, basic user guide will be prepared.
AM will undergo relatively minor refinements will be made during this period, with little or no backwards compatibility impact. In particular, AM will be updated to take advantage of the Ant PropertyHelper mechanism and other capabilities introduced in Ant 1.6 (most notably namespaces).
A final scope and architecture for CCB will be defined, together with an enhanced CSAR (Component State Archives) format.
A more highly functional Eclipse-based assembly line editor will be implemented, along with pre-defined assembly line libraries.
To the extent feasible, Ant may be replaced as the underlying make engine by a more traditional make engine, in order to make AM more palatable for C/C++ or other non-Java development efforts.