Farrago Packaging
Overview
This document provides an overview of how the Farrago frameworks and
plugins are built and packaged. Please read the architecture overview first.
Build Configuration
With a pluggable architecture, figuring out what needs to be built and
how in order to create a useful specialized distribution can be a
major headache. Our plan is to follow the Linux kernel
configuration process at an abstract level, though of course the
details are different:
- Development organizations such as The Eigenbase Project will
maintain a master list of all contributed components, together with
their dependencies and licensing requirements. This list will be
included in all downloaded source distributions.
- Projects wishing to incorporate additional non-contributed
components can maintain their own private lists as well.
- The configuration process takes the union of the above lists as
input, together with project-specific directives for which components
to include and how they should be packaged. An interactive tool will
be supplied for specifying these directives
- TODO: add a dependency validation step to the digram
- As its primary output, the configuration procedure produces a
number of build scripts (whose steps are outlined in the rest of this
document.
- In addition, the configuration procedure produces a description of
the licenses required in order to distribute the result of the build.
For example, these requirements might state "This system may be
distributed under the GNU GPL or under a commercial license from
Companies X and Y".
NOTE: in the diagram above and in those which follow, the meaning of
the pseudo-flowchart symbols is as follows:
Assembly Line
Once the top-level build scripts are defined for a particular
distribution, the procedure for building the various core and
extension components is as follows:
The result of this assembly line is a number of individual modules
which have not yet been packaged into a redistributable form, plus an
uninitialized catalog database. Further steps depend on the nature of
the distribution to be produced (as covered in the next two sections).
System Packaging
One option is to package a distribution for an entire working system,
as follows:
After plugin jars are built, the Initialization process
performs enough bootstrapping to be able to load all required
components and run site-independent initialization scripts. The
result is an initialized site-independent catalog database; this must
be included in the final packaging together with the executable
components, and serves as a base for site-dependent initialization
when a distribution is deployed. Of course, other resources such as
documentation should be included in the final packaging, but are not
shown here.
Plugin Packaging
The other distribution option is to package only individual plugins,
with the intention that they be used together with some other full
system distributions. In this case, it is a requirement that such
plugins consist of only code, without model extensions, although the
plugins are allowed to depend on model extensions provided with
specific system distributions. The plugin-only packaging process is
much simpler:
The diagram above illustrates the most general case of both Java and
C++ code being required to implement the plugin.