Declarative Dependencies

Projects should be able to declare dependencies without being concerned with where those dependencies reside, or in what form.  Dependency information is also needed for documentation and issue tracking, so it should be easy to automatically extract this information for use in other contexts.

A project should only need to declare its direct dependencies.  Indirect dependencies should be included automatically. 

Dependency information is stored and versioned along with the project source.

Automated Updates

Multiple parallel lines of development need to be constantly integrated to tighten the feedback loop.  As the number of projects grows, it will be impractical for each developer to update and build each project.  The build system should provide the capability for a developer to update dependencies from an online repository.

For example, instead of having to checkout and build the MicroContainer to test if a recent change affects the Application Server, it should be possible to call an ant target which downloads the most recent build. 

There will be cases where an updated dependency will introduce critical bugs which prohibit a downstream developer from moving forward. Therefore, it should also be possible to revert an artifact dependency to a previously working version. 

Source Artifact Overrides

It should be possible to work with multiple projects at once.  A developer should not be required to copy artifacts by hand when testing the integration between two projects.   Therefore, it should be possible to override a binary version of a dependency with its source artifact.  The build system may dictate a naming convention and work directory location for source artifacts.

Succinctly, it should be possible to use an artifact instead of a library simply by checking out the library&146;s project.

The balance between using the source of a dependency and using its pre-built library from the online repository is one of personal choice and circumstance.  The build system should be flexible enough to support both modes, and make it painless to switch back and forth.

This seems like an optional feature which can be satisfactorily replaced by an IDE (?)

Dependency Version Reconciliation

Each project depends on a specific version of a dependency.  However, when projects are aggregated into a project such as the Application Server, they must depend on the same version of a given artifact.  We can&146;t be shipping 3 versions of log4j in the application server.

Either the build system should be able to detect version conflicts in the dependency tree and report them as errors during the build cycle, or it should allow the container project to define library versions for all dependent artifacts.

Storing Binaries in Project VCS

This document does not proscribe whether projects should store dependency binaries in their Version Control System.  While this is current common practice, it is an unnecessary burden on project maintainers.  Due to continuous integration requirements, there will need to be an online repository for source artifacts, so its existence is a baseline requirement.

Source releases can be built with the required dependencies included.  This should have no effect on a project&146;s decision to store binaries in source control.