Build repositories are required to set the class lookup resolution appropriately in order for proper incremental build handling.

The registry is used during serialization of objects during builds. This is prevalent when the incremental state of the build execution is persisted, and during builds with clusters.

If the associated build repository fails to set up the class resolution, then it will result in failures during serialization of build results, using clusters will fail, or generally incremental builds will most likely not work.

Build repositories are required to modify the class resolution appropriately, when change detection results in modifications.

Build repositories are required to unregister their installed resolvers when they are closed.

The repository identifier is specified by the user to reference the repository by a specific name. If an identifier was not set by the user configuration, an automatically generated one is used.

The method returns the file provider for the build execution machine. That is the one that coordinates the build and runs it.

This method can be useful for repositories that were initialized on build clusters and need to access files on the coordinator machine.

This method may return different path configuration objects when the build system cache state is invalidated or rebuilt in some ways. However, even if different path configurations are returned, they can only differ in backing file provider objects, and they will not be different configurations.

Such scenarios can happen when connections to remote file providers are broken up and then reestablished later. In these cases using the previously returned file providers will most likely result in RMI errors.

Callers are recommended not to cache any file providers acquired from this configuration.

While this method can return different objects, it will not return different objects while a build execution is running. In general, clients only need to deal with this in BuildRepository.detectChanges() and related methods.

Shared objects are used to convey some build repository specific information to the remote build clusters. Shared objects can be set on the coordinator machine and they can be retrieved on all build machines that take part of the build execution.

When a shared object is set, the build repositories that are initialized on remote build clusters can retrieve these objects and modify their behaviour based on them. They can also be used to communicate with the build repository on the coordinator machine.

Generally shared objects are used to ensure that build repositories are properly loaded on the build clusters in the same way as on the coordinator.

Shared objects are private to each loaded repository. Shared objects cannot be retrieved for other repositories of the build execution.

If a shared object is transferred as a remote object, then callers should take care when calling remote methods. The connection may be lost between the build cluster and the coordinator at any time. Remote methods shouldn't be called when the build repository is closing as the RMI connection may've been broken up by then.
You may also need to requery the remote shared objects in BuildRepository.detectChanges() as if the remote repository is reloaded, RMI calls may fail with incompatible class errors.

This method returns true if and only if this build repository was intialized in order to take part of a build cluster execution.

If a build repository is initialized as a cluster, setSharedObject will always throw an UnsupportedOperationException.

Sets the shared object for the given key, or removes it if the value is null. This method can be called on the coordinator machine.

See getSharedObject(Object) for detailed explanation.