Open jjohannes opened 1 month ago
We should not publish from the hedera-services
repository. These should be defined in their own repository and all publishing should happen via CI under our Gradle Plugins Repository SA.
Nothing to add here; it is a great idea. Also, I agree with Nathan that it should have its own repository.
I like this proposal.
Thank you all for the feedback. Doing this in a separate Git repo from the start as proposed by @nathanklick sounds good. Not only for the publishing (credentials) and pipeline, but also for having a dedicated place for the Gradle configuration and it's documentation. I think it will make doing documentation and discovering documentation simpler.
I'll adjust the proposal accordingly.
How should the repo be named?
https://github.com/hashgraph/hedera-services/hedera-gradle-conventions ?
With the publishing coordinates (for the Jar containing the plugins) being com.hedera:hedera-gradle-conventions
?
@jjohannes give me a few days to work up a good name for this repo.
Problem
Many repositories in the github.com/hashgraph organization use Gradle to define their project structure and build (compile, test, check, ...) the code. The currently most sophisticated setup is the one in this repository hedera-services. In the past, the configuration in this repository was often copied when new repositories were created. This approach has a number of downsides:
hedera-services
is "more stable" now, it is still in flux and there are areas to improve it further. In the past, larger changes were made from time to time (e.g. in which folder Gradle config is located). We now have inconsistency in the different repos, where the same things are named differently or are located in different locations.Solution
General solution idea
Gradle plugins can be published to Maven repositories, just as we publish Modules to repositories. Technically, any Maven repository can be used, but there is a "Maven Central for Gradle Plugins" called the "Gradle Plugin Portal" - https://plugins.gradle.org/ - that may be used to publish open-source plugins.
We use the approach of Convention Plugins to configure the Gradle setup already. Technically, Gradle makes no difference between Convention Plugins and other "types" of plugins. Hence, we could publish the plugins we have defined in gradle/plugins/src/main/kotlin in as they are. Then we can reuse them in other repositories.
Most of the convention plugins are not specific to hedera-services already. Which means they are almost good to be reused in another context/repository.
Concrete Proposal:
com.hedera.gradle.convention.<aspect>.gradle.kts
. These plugins should work in a way that they can be used independently and individually. (While doing this, also improve documentation #11568.)com.hedera.gradle.conventions.java-compile
com.hedera.gradle.conventions.javadoc
com.hedera.gradle.conventions.test
com.hedera.gradle.conventions.shadow
com.hedera.gradle.conventions.jpms
com.hedera.gradle.conventions.jmh
com.hedera.gradle.conventions.spotless
includeBuild("...")
feature before actually publishing the plugins.com.hedera.gradle.convention.java-compile
can be read as "Hedera's Gradle Conventions for Compiling Java Code" - which other projects (outside of Hedera) could also use. Similar to how we use code formatting styles defined by other orgs/companies. This should be done via GH actions in the new hedera-gradle-conventions repository.Alternatives
No response