Base documentation can be found on the documentation website.
Developer documentation can be found under docs/developer,
where the main concepts and decisions are captured as decision records.
This is the primary extension point for the connector. It contains all necessary interfaces that need to be implemented
as well as essential model classes and enums. Basically, the spi modules defines the extent to what users can
customize and extend the code.
Contains all absolutely essential building that is necessary to run a connector such as TransferProcessManager,
ProvisionManager, DataFlowManager, various model classes, the protocol engine and the policy piece. While it is
possible to build a connector with just the code from the core module, it will have very limited capabilities to
communicate and to interact with a data space.
This contains code that extends the connector's core functionality with technology- or cloud-provider-specific code. For example a transfer process store based on Azure CosmosDB, a secure vault based on Azure KeyVault, etc. This is where technology- and cloud-specific implementations should go.
If someone were to create a configuration service based on Postgres, then the implementation should go into
the extensions/database/configuration-postgres module.
Launchers are essentially connector packages that are runnable. What modules get included in the build (and thus: what
capabilities a connector has) is defined by the build.gradle.kts file inside the launcher subdirectory. That's also
where a Java class containing a main method should go. We will call that class a "runtime" and in order for the
connector to become operational the runtime needs to perform several important tasks (="bootstrapping"). For an
example take a look at
this runtime
Contains implementations for communication protocols a connector might use, such as DSP.
See how to contribute.