IHub Plugins Documentation

repository·main·Indexed 20 days ago

https://github.com/ihub-pub/plugins

A comprehensive suite of Gradle plugins providing standardized infrastructure for JVM projects. Features include dependency management via BOM, multi-language support (Java, Groovy, Kotlin), Spring ecosystem integration with GraalVM Native support, and tools for CI/CD, code quality, and AI tool integration. Includes core plugins like pub.ihub.plugin.ihub-settings and pub.ihub.plugin for automated repository and project configuration.

Tokens
23.1K
Snippets
90
Records
135
Agent score
71%

What's inside IHub Plugins

  1. Overview of IHub Gradle Plugins

    main

    The pub.ihub.plugin suite provides specialized Gradle plugins for managing different aspects of the project lifecycle, including settings, dependency management, language configuration, and publishing. Use these plugins to standardize build logic across subprojects.

    | Plugin ID | Module | Purpose |
    |-----------|--------|---------|
    | `pub.ihub.plugin.ihub-settings` | ihub-settings | Settings plugin, auto-aggregates subprojects |
    | `pub.ihub.plugin` | ihub-plugins | Base plugin, repositories and extensions |
    | `pub.ihub.plugin.ihub-bom` | ihub-bom | BOM dependency management |
    | `pub.ihub.plugin.ihub-java` | ihub-java | Java project configuration |
    | `pub.ihub.plugin.ihub-groovy` | ihub-groovy | Groovy project configuration |
    | `pub.ihub.plugin.ihub-kotlin` | ihub-kotlin | Kotlin project configuration |
    | `pub.ihub.plugin.ihub-boot` | ihub-spring | Spring Boot integration |
    | `pub.ihub.plugin.ihub-test` | ihub-verification | Test task configuration |
    | `pub.ihub.plugin.ihub-verification` | ihub-verification | CodeNarc/PMD/JaCoCo |
    | `pub.ihub.plugin.ihub-publish` | ihub-publish | Publish to Maven Central |
    | `pub.ihub.plugin.ihub-git-hooks` | ihub-githooks | Git hooks automation |
    | `pub.ihub.plugin.ihub-skills` | ihub-skills | AI skills integration |
  2. Overview of IHub Plugins

    main
    IHub Plugins is a suite of Gradle plugins designed to provide essential infrastructure for Gradle projects, significantly simplifying project configuration. It offers features such as zero-config defaults, highly extensible property systems, unified BOM dependency management, multi-language support (Java, Groovy, Kotlin), and deep integration with the Spring ecosystem (including GraalVM Native support). It also includes built-in tools for code quality, testing, and publishing to Maven Central or the Gradle Plugin Portal.
  3. Use the ihub-meta plugin to generate project metadata

    main

    The ihub-meta plugin (ID: pub.ihub.plugin.ihub-meta) generates a project-meta.json file containing project structure metadata. This file is designed to be read by LLM/AI development tools to help them understand your project's architecture, dependencies, and source sets.

    Generated Metadata Content:

    • project: Name, group, version, description, and root directory.
    • gradle: Gradle version and applied plugins.
    • sourceSets: Source directory structure (main/test, supporting Java/Groovy/Kotlin/Resources).
    • dependencies: Dependency information (e.g., implementation, testImplementation).
    • modules: List of subprojects/modules.
    # Run the task to generate metadata
    ./gradlew iHubMeta
  4. Automatic Lombok configuration generation

    main

    If no lombok.config file is present in your project, the plugin automatically generates one during the execution phase using the iHubLombokConfigTask. This task is compatible with the Gradle Configuration Cache and is a dependency for all AbstractCompile tasks.

    The generated lombok.config contains:

    config.stopBubbling = true
    lombok.addLombokGeneratedAnnotation = true
  5. Understand the plugin property resolution hierarchy

    main

    The plugin resolves configuration properties using four distinct sources. When multiple sources define the same property, they are resolved according to the following priority (highest to lowest):

    1. Sys (System Properties): Passed via command line using -D (e.g., -DiHub.property=value).
    2. Env (Environment Variables): Defined in the OS environment. Use uppercase with underscores (e.g., PROPERTY_NAME=value).
    3. Ext (Extension Properties): Custom plugin extensions configured in your build.gradle file.
    4. Prj (Project Properties): Defined in gradle.properties using the format extension.propertyName (e.g., iHub.propertyName=value) or passed via command line using -P (e.g., -PiHub.propertyName=value).
  6. Understand the configured component repositories

    main

    The ihub plugin manages several repository types to ensure compatibility with different network environments (especially for users in China). The managed repositories include:

    • ProjectDirs: Local project components located at {rootProject.projectDir}/libs.
    • MavenLocal: The local Maven repository at {local}/.m2/repository.
    • AliYunPublic: AliYun public aggregate repository (https://maven.aliyun.com/repository/public) which includes https://repo1.maven.org/maven2.
    • ReleaseRepo: Private release repository.
    • SnapshotRepo: Private snapshot repository.
    • CustomizeRepo: Custom repository.
    • MavenRepo: Maven Central repository.
  7. Configure Jacoco test coverage

    main
    The jacoco plugin is used to check code coverage across three dimensions: bundle branch coverage, bundle instruction coverage, and package instruction coverage. For multi-project builds (main projects), the jacoco-report-aggregation plugin is added to aggregate reports.
  8. Understand IHub Property Priority and Best Practices

    main

    Property Priority

    When configuring IHub, properties are resolved in the following order (highest to lowest):

    1. -DiHub.xxx=value (Command-line system properties)
    2. IHUB_XXX=value (Environment variables)
    3. gradle.properties file
    4. @IHubProperty(defaultValue = ...) (Plugin default values)

    Version Management

    • Centralize Versions: All dependency versions should be managed in gradle/libs.versions.toml.
    • Avoid Hardcoding: Do not hardcode version numbers in individual module build.gradle.kts files.

    Gradle Best Practices for IHub

    • ✅ Use tasks.register() instead of tasks.create().
    • ✅ Use layout.buildDirectory instead of buildDir.
    • ✅ Use ListProperty<T> instead of Property<List<T>>.
    • ❌ Avoid afterEvaluate; use Provider.map() instead.
  9. How ihub-version manages project versions

    main

    The ihub-version plugin integrates and enhances two third-party Gradle plugins to manage project versions:

    1. io.freefair.git-version: Automatically configures project versions. ihub-version enhances this by supporting inferred version numbers based on Git tags.
    2. com.github.ben-manes.versions: Used to check component versions. ihub-version enhances this by supporting automatic replacement of the latest versions.

    Version Inference Details: Since version 1.9.5, version inference uses GitDescribeValueSource (via ProviderFactory.of(ValueSource) and ExecOperations) to call git describe --tags. This implementation is compatible with the Gradle Configuration Cache (CC).

  10. Understand plugin configuration scopes and sources

    main

    When configuring plugins in this ecosystem, properties and settings are sourced from different Gradle and system scopes. Use the following mapping to determine where to define your configurations:

    • Project-level plugins (Project): Configured within the build.gradle file. These define project-type plugins.
    • Settings-level plugins (Settings): Configured within the settings.gradle file. These define configuration-type plugins.
    • Plugin Extensions (Ext): Custom extension properties defined within build.gradle to customize plugin behavior.
    • Project Properties (Prj): Properties defined in the gradle.properties file, using the format extensionName.propertyName.
    • System Properties (Sys): System-level properties, such as those passed via the command line.
    • Environment Variables (Env): Environment variables, which must be defined in all uppercase with underscores separating words (e.g., MY_VARIABLE_NAME).