The Packaging Tool is a VisualWorks Smalltalk class library that provides structures for constructing and configuring software packages as basic components of applications.

When building an image for either a run-time application or a development environment, patches, extra utilites, commercial add-ons, and modules for the application need to be filed in. These code segments often make use of classes and methods not in the base VisualWorks image. To ensure that all the code is filed in the right order, dependencies between the code pieces need to be established. This can be accomplished by grouping the code segments into packages and setting up dependencies between the packages. Building a customized image then just requires specifying which packages are desired.

The Packaging Tool provides a simple interface for specifying which packages are needed with any dependencies (on other packages) they may have.

The Packaging Tool interface consists of two views. The browser view has four SelectionInLists for the images, packages, files, and dependencies. It was designed with the VisualWorks class browser in mind. There is also an ObjectGraph view which is a visual representation of the dependencies between packages.

Images

Adding/Removing
Images can be added and removed from the Images pop-up menu. All images currently in the Packaging Tool must have unique names. Removing an image removes all packages within the image and all dependencies on the packages.

Settings
The settings interface allows for the specification of a source file which will be targeted while filing in the packages. Any pre-build or post-build code entered will be executed at build time. The code is not checked for syntax errors so if the syntax is wrong, a runtime error will occur.

Building An Image
Building an image will file in all the files associated with the packages in the image. If packages have unsatisfied dependencies, conflicting dependencies on packages which are part of the image, or contain files which do not exist, the image cannot be built. The conflicting packages and unstable dependencies menu items will list all of the conflicting packages and unstable dependencies for a given image.

Filing Out/Loading
Filing out and loading an image is the same as filing in/out classes. Caution should be used when loading an image into the Packaging Tool when an image by the same name already exists. If the user chooses to overwrite the current image, the current image will be removed and the new will be loaded. This will remove all dependencies other packages have on the packages in the image.

Image Instability
Images can become unstable if dependencies exist on packages that no longer exist. The problem arises only when images have packages which have dependencies on packages in other images. If these images are filed out and then brought back at a later time, the image may become unstable. If only one of the images is filed in and its packages have dependencies on the other, those dependencies are no longer satisfied. The graph will not be drawn until the image is stable again. The unstable dependencies menu item in the images list pop-up menu will list all the dependencies in the image that are not currently satisfied. Once the other image is loaded or the dependencies are removed, the image will become stable again and the graph will be drawn.

Packages

Packages must have unique names across all images. Packages have the same adding, removing, filing out, loading functionality as images. Packages have different settings though. Package Settings allow pre-build and post-build code, and the specification of identifying classes. Identifying classes allow for checks to be made on the current system dictoionary to determine whether or not a package's files need to be filed in. They also are used to determine whether or not conflicting packages are currently in the system.

Files

Files can be simply added or deleted. The only requirement is that the file exists.

Dependencies

Dependencies can be added and removed. Dependency names are determined by the parent package name and the type of dependency. Dependencies have been color coded on the graph by type.

Dependency Types

Strong black A package must be filed in before the dependent

Weak green A package must be filed in with the dependent (not necessarily before)

Conditional blue A package is not dependent on a second package, but if the second package is filed in, the first must be filed in after the second.

Conflicting red Two packages can't be filed in together.

Design

The Packaging Tool consists of 5 classes: PackagingTool, ImageData, Package, PackageDependency, and SettingsInterface. It also makes use of the ObjectGraph classes.

The PackagingTool object provides the interface for manipulating the ImageData, Package, and PackageDependency objects. PackagingTool is dependent upon both Package and PackageDependency. PackagingTool and SettingsInterface are both subclasses of ApplicationModel. A Package object can have many PackageDependency objects associated with it. An ImageData object manages a collection of Package objects. PackageGraphController subclasses ObjectGraphController so that events are handled rather than polled.

Future Enhancements

Editing images and packages through ObjectGraph.
Separating the browser from ObjectGraph. ObjectGraph will still be a part of the browser, but it can be made invisible. ObjectGraph can also be spawned off in a separate window.
Creating packages from classes in the image.
Pre-compiling pre-build and post-build code to check for syntax errors.
Better error handling when building an image. Errors at build time will no longer cause the build to simply be aborted.
Composite Packages ie packages which contain other packages.
Subgraphs will be displayed in ObjectGraph rather than the entire graph.
Packages will be able to have files that are available across the internet instead of being limited to only those available locally.

A good extension of the Packaging Tool would associate a URL with packages thereby globalizing the tool. Packages would be identified by the URL thus eliminating the need for all packages to be filed into the Packaging Tool in order to have a stable image. If one would want to build an image that contains a package that has a dependency on a package that is not currently filed into the Packaging Tool, the package could be retrieved at build time.

Installing The Packaging Tool

Ftp the file PackagingTool.tar, untar it, and file in the install.st file found in the PackagingTool directory.

This project was done under Professor Ralph Johnson at the University of Illinois, Champaign-Urbana.
Design by Josh Miller, Jeff Barcalow, Joseph Yoder.
Written by Josh Miller.