Publishing Maven Artifacts

[paullatzelsperger]

As demos/playgrounds/showcases begin to spin up and we want people to start using the EDC "SDK" we should start publishing maven artifacts.
Initially we could publish them publicly to our Github using "Github Packages" and publish them to MavenCentral later.

There are a few questions I'd like to address:

1. Naming scheme: can we come up with a consistent and intuitive naming scheme?
2. When do we publish: e.g. -SNAPSHOTs on every successful build on main, plus manually on a dedicated release branch, ...
3. Versioning scheme: are we okay with using SemVer and one version number across all packages?
4. Does there need to be some sort of special process when adding new modules to the code base, thus adding new Maven artifacts?
5. Are there any legal requirements, like including license files?
6. Are there any requirements from Eclipse regarding the aforementioned points?

@mspiekermann can you provide insight re/ the Eclipse question?
@alexandrudanciu do you have information about the legal aspects?

[alexandrudanciu]

@paullatzelsperger I started writing a documentation for developers addressing the questions raised by you. A PR will follow asap.

[paullatzelsperger]

Here is a proposal regarding naming scheme:

• group name is org.eclipse.dataspaceconnector
• artifact name generally reflects the directory structure, except the extensions and data-protocols part. Examples:
  • azure.blob.provision, aws.s3.provision
  • ids.ids-api-rest-dispatcher and ids.ids-api-rest-endpoint
  • core.bootstrap, core.schema, etc
  • iam.identity-did-core
  • in-memory.catalog.cache.store, in-memory.catalog.cache.protocol-registry, in-memory.process-store
  • filesystem.configuration

this will result in gradle dependencies that look similar to:

implementation("org.eclipse.dataspaceconnector:core-boostrap:0.0.1-SNAPSHOT")

[ndr-brt]

In my opinion we should add an edc- prefix to all the modules, it will help comprehension, it's a common pattern in multi-module projects (like Vert.x or Apache Camel, just to mention two of them)

[ndr-brt]

maybe also replacing dots with hyphens and avoid repetitions in naming (like ids.ids-api-catalog could be just edc-ids-api-catalog)

[paullatzelsperger]

In my opinion we should add an edc- prefix to all the modules, it will help comprehension, it's a common pattern in multi-module projects (like Vert.x or Apache Camel, just to mention two of them)

My screenshot did not show this, but the groupId is org.eclipse.dataspaceconnector, so a full package name would be something like org.eclipse.dataspaceconnector:in-memory.identity-hub:0.0.1-SNAPSHOT

[alexandrudanciu]

Regardless of the procedure and naming conventions around the distribution of software artifacts, I would like to discuss the intended scope of artifacts to be published. Beside the whole connector core (incl. submodules) also subsets (e.g., ids spi) could be published as maven artifact.

However, publishing an individual module promises the contribution of a public API which is subject to a managed lifecycle and release management. In my opinion, most of the modules (e.g., aws.s3.provision) are not intended to be reused outside of the EDC and should, therefore, not be published individually.

Modules explicitly contributing a public Java API (i.e., spi, ids spi, extension spi) of course represent an exception and should be published individually.

The approach which will soon be proposed (as part of a PR) will include an initial list of publishable modules which can be reviewed initially and curated on an ongoing basis. As a consequence, some modules will receive specialised gradle tasks and legal notice files.

[paullatzelsperger]

I think we must publish all modules as separate Maven artifacts, otherwise it will get messy. We can still publish BOMs (Bills of Material) to structure it further.

[jimmarino]

Yes, we need to publish every module, otherwise, things will not work since inter-module dependencies will not resolve. I would expect the Gradle publish plugin would likely fail as well.

We should keep in mind that publishing to a Maven repo is independent of whether an API is public or not. It's really just a software distribution mechanism. At some point, we should adopt semantic versioning, but IMO opinion this should not happen until version 1.0, which is a way off. Let's discuss.