Build Order
Often the order in which projects are built is important. For
example, if one project requires the Java classes which were defined in another
project, the first project must be built after its prerequisite classes have
been built. The Workbench allows users to explicitly define the order in
which projects are built. Alternatively, users can let the platform compute the
build order by interpreting project references as prerequisite relationships.
The build order is applied for both building the entire workspace or for a group
of projects.
You can change this order on the Build Order preferences page. Initially
the Use default builder order option is on, in which case the platform computes the
build ordering. Turning off this option enables access to the projects list, the
ordering of which can be manipulated. Select projects and use the Up and Down
buttons to change the build order. Add and remove projects in the build order using the
Add Project and Remove Project buttons. Projects removed from
the build order will be built, but they will be built after all projects in the build
order are built.
At the bottom of this page, there is a preference for dealing with build orders that
contain cycles. Ideally, you should avoid cyclic references between projects. Projects
with cycles really logically belong to a single project, and so they should be collapsed into
a single project if possible. However, if you absolutely must have cycles, it may take
several iterations of the build order to correctly build everything. Changing this preference
will alter the maximum number of times the workbench will attempt to iterate over the build
order before giving up.
Here is what the Build Order preference page looks like:
Builds
Project menu