-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shared Gradle Convention Plugins for Hiero #14255
Comments
We should not publish from the |
Nothing to add here; it is a great idea. |
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? |
@jjohannes give me a few days to work up a good name for this repo. |
I am making progress on this and would be ready to get started with the repo setup next week. Any thoughts on the name @rbair23? |
PRs to move to the common configuration: |
As discussed between @rbarkerSL and @nathanklick this should go directly under the Hiero namespace. Suggestion:
When using the shared configuration in a repository, it is sufficient to use the main plugin in
|
Need to create a PR on hiero-ledger to add a new repository |
See hashgraph/hedera-services#14255 Signed-off-by: Jendrik Johannes <[email protected]>
This is done. Three repositories have been switched to the setup (hedera-services, hedera-cryptography, hedera-sdk-java). Moving more repos to the setup is tracked in separate PRs/issues. Further improvements and fixes to the convention plugins are tracked here: |
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:
In the past, copying was done at arbitrary points. Possibly copying "undiscovered issue" that were then only fixed here, but not in the copies. There is no mechanism in place to track or even know about the copies.
Although the Gradle setup in
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.Even if we would somehow improve tracking the "copies" it would be quite some work to manually update all places if we make a change
Right now, setting up a new repo requires someone with a lot of expertise with the Gradle setup and the new setup is already doomed to be "imperfect" from the beginning (e.g. containing, in that context, unused configuration code).
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 Document the Gradle build configuration #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.When this is done, other existing and new repositories can use the convention plugins. If further development on the plugins is done, a new version of the plugins is published. Repositories then individually can decide to updated (or not yet update) to new versions. Then it is clear for each repository which variation (i.e. which version) of our Gradle configuration they use, which is much clearer than what we have now.
Alternatives
No response
The text was updated successfully, but these errors were encountered: