Build System Requirements

This page is intended to be the requirements document of the Kepler build system.  The requirements are in no particular order.  They may be reordered later.

R1) The build system should support the modularization of Kepler.

• The build system should be able to build single modules/extensions as well as suites of modules and extensions in a single command (after configuration), making it easy for a developer to be simultaneously changing multiple modules in a coordinated way
• Enable developers to choose which version of Kepler their extensions are meant to work with.

R2) Checkout/in of the modules should be simple and use our chosen source code management tools (i.e., svn).

• Only the source code management system should be needed to check out all modules managed in the Kepler SVN.  Requiring a script or external application to successfully checkout Kepler makes it harder to use a diverse toolset (e.g., without ant support) or make future changes to the build or repository system.

R3) The build should be simple, command line accessible, and make use of an explicit script.

• A user should be able to transparently understand the whole build via the build file. 
• The build should not rely on compiled source code unless alternative more transparent scripts in ant would suffice, since it makes it difficult to maintain and understand.

R4) The Kepler repository should be arranged in a manner that is consistent with the modularization of the application, and these modules should remain intact during the build.

• The build system should not permanently restructure the Kepler repository in order to build it.  If any restructuring occurs, it should be in a non-permanent way so that developers can change and check in files in their current locations.

R5) The build system should maximize maintainability by minimizing the need for overriding files.

• Module maintainers should ensure overriding files are checked in and versioned, and should be avoided where possible to prevent maintenance issues.

• The build should instead directly support alternative versions of modules, but these must be checked in. 
• Eliminate the exp/ directory due to maintenance problems.

R6) The build system should be based on a simple scripted build system (i.e., ant) and should also support multiple IDE's.

• The build should maximize portability to other IDEs and not use any custom ant tasks that would inhibit an IDE.
• Copying/moving files during an ant build should be minimized and the repository should always be able to be returned to a pre-compilation state by running the "clean" command.

R7) The build system should allow optional module-specific builds, so that if a module is checked out individually, it can be built directly.

R8) The build system must integrate with the NMI build system (NSF requirement).

• NMI builds should be able to build the kernel and standard extensions every night
• The NMI build should be able to be configured to also build and test various extensions and combinations of extensions as needed, which may require multiple builds each night
  

R9) Provide a way to flexibly version, share, and maintain source code for Kepler extensions.

R10) Enable developers to experiment with alternative implementations of classes in the Kepler kernel without creating a complete branch of the kernel.

R11) Support extensions to Kepler that use versions of third-party libraries (i.e., jars) different from those used in the Kepler kernel or in other extensions.

R12) Make it easy to declare what 3rd party libraries are required by particular Kepler extensions and to package these libraries with the extensions.

R13) Make it easy for new developers to get started developing with Kepler and to set up their development environments.

R14) The build system must have a target that can be used to build stand-alone installers for Mac, Windows, and Linux platforms

• Implementation should use the current XML-configured IzPack installer system which has been tested on all 3 platforms and is currently working well
• Should support adding in various extensions and dependencies in a distrbution (e.g., R)
• Should be able to make installers with and without an included JRE
  

R15) The build should have a target that generates all API documentation for Kepler and Ptolemy and makes it available for developers to browse and search in their local working copy, and should make it easy to publish this API documentation on the Kepler web site

R16) The build system must support storage and execution of various system tests both by developers and in the automated build

• Unit tests through JUnit should be supported
• Regression tests should be supported
• Possibly support Tcl test (ala Ptolemy's test suite)
• Support workflow execution tests (testing I/O of actors and workflows)