The aggregate’s API is the set of resources, topics in this case, that the aggregate is exposing to the rest of the organisation. Serves in other aggregates can access the resource metadata via the aggregate descriptor. To enable this, the api needs to be published somewhere!
IngestionAggregateDescriptor added to the
services module should not be published.
servies jar should be private to the repository. If the ingestion aggregate is accessed by more than one Creek
aggregate, then the
IngestionAggregateDescriptor should be declared in a shared location and packaged in its own
How and where an organisation publishes jars will vary, so configuring the publishing is outside the scope of this tutorial. However, Creek doesn’t leave you completely stranded either.
Publishing to GitHub packages
The aggregate template, and hence the completed tutorial available on GitHub, comes pre-configured
to publish the
api module to GitHub packages, which provides a Maven repository where jars can be published.
Publishing is configured in the
You’ll notice a
ChangeMe comment in there, encouraging users to think about where their
api jar should be published.
api can be viewed in GitHub alongside the service’s docker container.
Are GitHub packages right for your organisation?
At the time of writing GitHub packages aren’t meant as a way of publishing public artifacts,
(though there is a workaround),
but they are perfect for sharing artifacts within an organisation.
That said, if your organisation already has a standard way of sharing Java artifacts, the
api jar should be published there,
ready for others to download and use.