An instance of this interface is passed to the build repositories during instantiation. They can operate based on the configuration data available in this interface.
Build repositories are required to set the class lookup resolution appropriately in order for proper incremental build handling. (See getClassLoaderResolverRegistry())
The result of getter methods in this interface are considered to return the same objects, unless otherwise noted.
Gets the registry for class loader resolvers which is used during build execution.
Gets the identifier which was used for this repository.
Gets the path configuration used by the build execution.
Gets the core build environment for the repository to use.
Gets the arbitrary parameters which were specified by the user for the build execution.
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.
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.