Should we publish our Gradle Plugins to the Gradle Portal?

[paullatzelsperger]

Currently, EDC Gradle Plugin, most importantly the edc-build plugin, is being published to OSSRH Snapshots and MavenCentral.

We could also publish the Gradle plugins to the Plugin Portal, which would improve discoverability and ease-of-use, especially for non-EDC projects, because then it can be applied by-ID, for example:

plugins {
  id("org.eclipse.edc.edc-build") version("X.Y.Z")
}

There is another advantage: we could avoid the workaround where the build plugin is basically applied "onto itself", which seems kind of ... iffy.

It should be noted that the Gradle Plugin Portal does not allow snapshot builds. We could still align the release versions with other EDC components, but every component would have to maintain the plugin version separately.

Another aspect is that the publish process to the Plugin Portal differs from MavenCentral, and there is an approval process involved:

It also needs to pass an approval process, which is manual and relatively slow for the initial version of your plugin, but is fully automatic for subsequent versions

To me, this would be grounds for decoupling the Gradle plugins release process from the rest of the EDC components.

Personally, I don't think that is a big issue though, because the plugin would get treated like just another dependency, and it doesn't change that often anyway. Dependabot can take care of updates.

[ndr-brt]

I think this is a good idea.
Actually what we could do could be to split the autodoc processor from the edc-build plugin, this will permit to remove the runtime-metamodel dependency from the edc-build plugin (and the chicken-egg problem) so the plugin could be released separately from EDC, while the autodoc-processor will continue to depend on the runtime metamodel and be released together with EDC.