Build Artifact Repository Defined

A build artifact repository is a build artifact management tool designed to support automated publication and consumption of build artifacts. Artifacts within an artifact repository are organized with machine navigable namespaces, versions, and other meta-data constructs.

Example build artifacts typically stored within an artifact repository include:

• Compiled binary libraries (shared object files, dynamic linked libraries, Java JAR files, Python distribution archives)
• Archives of the source associated with compiled binaries
• Debug symbol and memory map files
• Documentation auto-generated by extracting documentation in-line with the source code (Javadoc, Doxygen output, etc.)
• Archives of test results
• Any other build system output

A Build Artifact Repository is not a Source Control Repository

The features and intent of a build artifact repository should not be confused with the needs of a source control repository. Source code repositories such as ClearCase, Subversion and Git are designed for effective organization of the Original Expression of Intent.

Examples of Original Expression of Intent include:

• C/C++ source files
• Java source files
• Word documents
• MATLAB models
• Visio diagrams

In contrast, the following are build artifacts, not Original Expressions of Intent:

• Auto-generated C code from a MATLAB model
• Source archive co-generated along with a binary library

Build Artifact Repositories serve IDEs Too

Build artifact repositories make it possible for a downstream code-base to easily consume upstream libraries. Although this is the primary use case, it is not the only one. Build tooling must address the needs of developers as they author new code and diagnose bugs in existing code. This is why you often see artifacts such as source file archives, debug symbol file archives, and the like in an artifact repository.

A developer will frequently request that the build tooling download not only the upstream binaries, but also the corresponding source files and documentation archives. A developer can then easily configure his/her debugger to step down into, and navigate within, the source code of a referenced library.

As the tooling within a language ecosystem evolves, it will likely proceed along the following path:

1. The build system supports pulling down the referenced libraries and related files, and dropping them in a known location. Configuring a debugger and/or IDE to be aware of the libraries, their sources, debugging symbols, and the like remain the responsibility of the developer.

2. The build system evolves to auto-generate an IDE project file with all the library references pre-configured.

3. The IDE evolves to read the build system configuration itself and auto-configure the library references.

Each evolutionary stage is an improvement over the one before it, but even the first stage is very workable.