Core API
The Indy core API defines the basic interfaces, event types, exception types, and utility classes necessary for its fundamental repository management functions. Its interfaces define methods for the following:
StoreDataManager- creation, retrieval, and management of artifact store (repository and group) definitionsContentManager/DownloadManager- retrieval of content given a path and an artifact store, including decorator interfaces to support merging and generating contentIndyFeatureConfig,IndyConfigFactory, and friends - configuration of the system, including the flexibility for add-ons to define their own configuration subsectionsIndyLifecycleManagerand friends - system lifecycle traversal (boot, migration, startup, and shutdown activities)
The event types specified in the core API define the basic events that flow through the system as store definitions are changed and content is accessed. Any subsystem or add-on can choose to respond to these events using CDI @Observes annotations. Likewise, exceptions defined here describe basic failure types that can be generated by implementations of the core API.
Finally, the utility classes in this API are available everywhere within the Indy server runtime (but NOT in client API modules!).
Exceptional Cases
In some rare cases, full implementations are provided in the core API. These generally cover cases where it doesn’t make sense to have more than one possible implementation. In other cases, abstract classes are provided that implement one interface or another, as a convenience that allows implementors to selectively override the default (normally empty) methods.
In still other cases, the core API provides integration code (wrapper objects, CDI Producer classes/methods, etc.) necessary for integrating with the major external apis Indy uses, such as Galley (used for file transport and cache management).
API Deeper Dive
Let’s take a closer look at the core API interfaces we enumerated above:
Artifact Store Definitions
Artifact stores are locations where artifacts might be stored. These can be remote proxies (RemoteRepository), locally hosted locations (HostedRepository), or virtual collections of other stores (Group). Each store has configuration parameters associated with it. Groups have a name and a list of member-store keys, while RemoteRepository instances have at least a name and a remote base URL (they have many other configuration options, most of which have default values that can be used). Even HostedRepositories, which only require a name, have configuration options defining what type of artifacts and activities are allowed, along with optional configuration for its storage directory.
The point of all this is to illustrate that artifact stores have non-trivial definitions…and these definitions have to be stored somewhere so they can be created, retrieved, and managed over the long term. These activities are encapsulated in the StoreDataManager interface. It defines basic CRUD-type methods, along with a few notable extra methods for special cases, like:
- retrieving the full membership of artifact stores for a group (groups can be members of other groups).
- finding any RemoteRepository matching a given base URL
- finding groups containing a given artifact store
Additionally, StoreDataManager defines methods for loading, reloading, and clearing store definitions from some type of long-term storage.
Content Management
TODO
System Configuration
TODO
System Lifecycle
TODO