IHub Plugins: a shared configuration layer for Gradle builds

Build infrastructure as plugins rather than copied scripts

IHub Plugins is a set of Gradle plugins that provide infrastructure for Gradle projects and simplify project configuration. The repository description in Chinese says the same thing more directly, calling it a plugin set that greatly simplifies project management, and the plugin list is broken into core plugins, language support, dependency and framework plugins, and a group for verification, build and tooling.

The problem being solved is familiar to anyone who has maintained more than one Java repository. A Gradle build accumulates infrastructure: which repositories to resolve from, which versions of which plugins, how a BOM is imported, how the fat JAR is assembled, which static analysis and coverage gates run, how the artifact is published. Each of those is a few lines of configuration, and each of those lines gets copied into every new project and then drifts.

The stated properties of the set are that it works out of the box with zero configuration and defaults that follow best practice, that it is highly extensible through a flexible extension property system with several levels of configuration, that it manages dependency versions through a unified BOM, that it supports Java, Groovy and Kotlin natively, that it integrates deeply with Spring Boot and supports GraalVM native compilation, that it includes code quality tooling such as static checks and test coverage, and that it makes publishing to Maven Central and the Gradle Plugin Portal straightforward.

The projects are published to the Gradle Plugin Portal under the pub.ihub.plugin identifier, and the source is Apache-2.0 licensed. The primary language is Groovy, with a build.gradle.kts and a buildSrc/ directory in the tree, and the documentation lives at doc.ihub.pub/plugins rather than in the repository.

A settings plugin first, then the project plugins

The entry point is a Settings plugin, applied in settings.gradle or settings.gradle.kts:

plugins {
    id 'pub.ihub.plugin.ihub-settings' version '1.9.5'
}

The settings plugin is described as covering plugin repository setup, version management and subproject management. That ordering matters, because the settings plugin is what makes the rest resolvable: it configures where plugins are fetched from and which versions are in play.

Project-level plugins are then applied in build.gradle or build.gradle.kts, and the base plugin is the one applied without a version, since the version comes from the settings layer:

plugins {
    id 'pub.ihub.plugin'
}

The base plugin is described as the base plugin that configures component repositories and extension properties. So the pattern is a two-step application, one at settings level and one at project level, and the base plugin is where a project picks up repositories and the shared extension property system.

That extension property system is the mechanism behind the claim of flexible extension at several levels of configuration. A project does not edit the plugin, it sets properties on an extension block, which is the same shape as the Spring Boot Gradle plugin's own configuration, and it is what allows defaults to be sensible while remaining overridable.

A typical project block shows the BOM import in use:

plugins {
    id 'pub.ihub.plugin.ihub-java'
}

iHubBom {
    importBoms {
        group('org.springframework.boot').module('spring-boot-dependencies').

Note that the last line ends mid-expression, because the example in the project documentation is truncated at that point. The shape is clear regardless: an iHubBom block with an importBoms closure that takes a group and a module.

The version compatibility table is the first thing to read

Before any of this works, the Java and Gradle versions have to line up. The project publishes a compatibility table that maps a plugin version to a Java range and a minimum Gradle version.

The current line, 1.9.5 and later, requires Java 17 through 25 and Gradle 9.4.1 or later. The 1.9.4 line needs Gradle 9.3.1 or later with the same Java range, 1.9.3 needs Gradle 9.3.1, 1.9.1 and later need Gradle 9.1.0, and 1.9.0 drops to Java 17 through 24 with Gradle 9.0.0. Older lines go further back: 1.7.6 and later cover Java 17 to 23 with Gradle 8.13, 1.7.2 with Gradle 8.4, and 1.5.6 with Java 17 to 21 and Gradle 8.0.

That table is the most useful operational fact in the documentation for an adopter. A Gradle plugin that sits between your build and the toolchain has to be upgraded in step with Gradle itself, and the table tells you which plugin line matches the Gradle you are on.

There is also a gradle.properties configuration block, and the example given in the project documentation turns on a local Maven repository and an Aliyun proxy repository for faster downloads:

iHub.mavenLocalEnabled=true
iHub.mavenAliYunEnabled=true

Both are opt-in and both are about where artifacts come from. The second one is worth thinking about in a corporate network, since a proxy mirror in the region can be the difference between a build that resolves and one that times out.

The plugin list, and what each one actually owns

The catalogue is long enough that it is worth grouping by what a build actually needs.

The core group is four plugins. Settings handles plugin repositories, version management and subproject management. Base is the project plugin for component repositories and extension properties. Version covers dependency version checking and automatic updates. Profiles provides Maven POM profiles that are compatible with Gradle versions, which is a translation layer for anyone whose build still leans on POM profile semantics.

Language support is three plugins, for Java, Groovy and Kotlin, each handling environment configuration and, in the Java case, default dependencies and compatibility, and in the Groovy case the component dependencies.

Dependency and framework is where the interesting work sits. BOM handles unified dependency version management and compatibility configuration, which is the plugin that imports something like the Spring Boot dependencies BOM. Boot integrates the Spring Boot plugin and Docker image configuration. Native adds GraalVM native ahead-of-time compilation support.

The verification and tooling group covers the rest of a release pipeline. Test configures test tasks and environment, Verification runs static code checks and test coverage, Publish configures artifact repository publishing, Shadow does fat JAR packaging, Javaagent handles dynamic bytecode instrumentation, Copyright sets a uniform copyright header in IntelliJ IDEA, GitHooks automates Git hook configuration, Node adds Node.js and cnpm runtime support, Meta generates project structure metadata as JSON for use by LLM and AI tools, and Skills installs AI skill files for Claude Code, Copilot and OpenCode.

The last two are the unusual ones. Meta and Skills push the plugin set beyond build infrastructure into developer tooling, which is a signal of where the project is heading: a build that knows its own structure well enough to describe it to a coding agent.

Where IHub Plugins is the wrong dependency

The first limit is the coupling to Gradle versions. Because the plugins sit between your build script and the toolchain, they force a coordinated upgrade. The compatibility table shows several distinct lines, each tied to a Gradle minimum, and a project that is deliberately on an older Gradle is pinned to an older plugin line with whatever fixes that line has or has not received.

The second is the indirection cost. A build that applies the base plugin inherits repository configuration and an extension property system it did not write. When a dependency fails to resolve, the person debugging has to know which layer set the repository, and there are several: the settings plugin for plugin repositories, the base plugin for component repositories, the BOM plugin for versions, and the gradle.properties settings for the local and proxy repositories. That is a fair amount of machinery to learn before you can change one thing.

The third is that the value scales with the number of repositories. For a single project, applying a plugin set to inherit a handful of repository declarations and a BOM import is more work than writing the four lines yourself, and you give up the ability to read the whole build in one file. The economics only work when the same infrastructure is being applied across many builds that would otherwise be copy-pasted.

The fourth is the trust boundary of the defaults. The claim is that the defaults follow best practice, which is convenient and also means your build's behaviour is defined by someone else's judgement, and it changes when you upgrade. A team with a strict opinion about, say, how fat JARs are built or which static analysis rules run may find that the opinionated default is a starting point to override rather than a solution.

The release numbering also signals where this sits. The recent tags are 2.0.0-m3, 2.0.0-m2 and 1.9.7-m1, so a 2.0 line is still in milestone builds while the 1.9 line is where the 1.9.5 version referenced in the quick start lives. A consumer on the 2.0 line should expect the API to still be moving.

Editorial conclusion

IHub Plugins fits a Java organisation that has more than one Gradle build and keeps copying the same repository declarations, plugin versions and quality gates from project to project, since the plugin set supplies those as a versioned dependency rather than as copied text. It is the wrong choice for a single project, for a team that wants full control of its build scripts, or for a build that must run on a Java version outside the supported range, since the plugin versions are pinned to specific Java and Gradle combinations. Before adopting it, apply pub.ihub.plugin.ihub-settings in settings.gradle and the base plugin in build.gradle, then check the compatibility table for your Gradle version, review the docs at doc.ihub.pub/plugins, and note that the last push was on 2026-10-19 with the newest release at 2.0.0-m3 from 2026-08-23.

Frequently asked questions

Official sources

1. ihub-pub/plugins on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases