In Section 17.5.3, “Interface Variables for Java Items”, we discuss the three classpath interface variables. These are as follows, described here from the perspective of the item that is using them:

Within the context of a Java build, there are four different types of classpath-like entities. We describe them here and show how they are related to the three classpath interface variables:

Each of the above classpaths is computed inside abuild's java rules. In each case, the computed value is used as a default value for attributes to the various targets that use them.

To override the value of one of these classpaths for a specific build item, there are two approaches. One is to effectively replace the interface variable with a parameter. Since abuild uses resolve internally to retrieve these values, constructs such as this:

parameters {
    abuild.classpath.manifest << 'something-else.jar'
}

or

parameters {
    abuild.classpath.manifest =
        resolve(abuild.classpath.manifest).grep {
            it != 'something-else.jar'
        }
}

can be used to change the underlying variables used to construct the various class paths. To understand why this works, please refer to Section 19.7.3, “Parameters, Interface Variables, and Definitions”.

The other way these can be overridden is to specifically override the classpath that is used by each target. This can be done by using control parameters, as discussed in Section 19.6, “Advanced Customization of Java Rules”. Each target's attributes map contains a key that can be set to supply a new value for whichever classpaths need to be changed.