Resolving build dependencies through manifest file

The MANIFEST.MF file in a jar file can be used to define runtime dependencies through the Class-Path attribute. In the manifest specification, it says:

Class-Path: The value of this attribute specifies the relative URLs
of the extensions or libraries that this application or extension needs. 
URLs are separated by one or more spaces. 
The application or extension class loader uses the value of this attribute
to construct its internal search path.

Since it explicitly states “application or extension class loader”, it is not completely clear from the specification that the Class-Path attribute is also considered by the javac compiler to resolve build dependencies. However, it is – this is the bug which introduced that feature in Java 5: Consider the following sample code which imports classes from some third party jar files:

package com.example;

import org.apache.log4j.PropertyConfigurator;

public class Sample {

   public static void main(String[] args) {
      Gson gson = new Gson();

      // ...

We can create a jar file like libs.jar with a Class-Path reference to the corresponding libraries:

$ cat manifest.txt
Class-Path: lib/gson-2.2.2.jar lib/log4j-1.2.17.jar

$ jar cvfm libs.jar manifest.txt
added manifest

By simply adding the libs.jar to the classpath when invoking javac, the additional jar files get pulled in:

$ javac -d bin -classpath libs.jar -sourcepath src src/com/example/

$ ls -la bin/com/example/Sample.class
-rw-r--r-- 1 andreas users 432 Apr  7 12:20 bin/com/example/Sample.class

A real-world sample where this is used is the Oracle Platform Security Services. There is only one jar file which needs to be added to the build path, jps-manifest.jar, which references all other required jar files through its Class-Path attribute.