diff --git a/README.md b/README.md index 01562cf..5bb04cc 100644 --- a/README.md +++ b/README.md @@ -1,18 +1,11 @@ -# Gradle Cookbook +# Cookbook Site - Shutdown Notice -Gradle Cookbook is an open-source collection of recipes, guides and examples for the Gradle Build Tool. -This is a complementary resource to the official Gradle User Manual, which covers core capabilities maintained by the Gradle team. +This repository previously contained documentation and examples. The site has been shut down and now redirects to the [Community Site](https://community.gradle.org). -The goal of this portal is to offer solution-based documentation for end users about external integrations, -including but not limited to CI/CD tools, IDEs, support for languages and frameworks, and various peripheral tools. +## What happened? -## Status +The cookbook site is no longer active. All documentation, examples, guides, and integrations have been moved or removed. -> **WARNING:** Gradle Cookbook is an incubating project that is yet to reach the critical mass of content. -> Any contributions will be appreciated! +## Repository status -## Contributing - -To contribute to this community repo, see [CONTRIBUTING.md](./docs/CONTRIBUTING.md). -To contribute to the Gradle community as whole, we have the contributor guide [here](https://community.gradle.org/contributing/). -All contributions are welcome! +This repository is maintained for archival purposes only. No further updates will be made to the content. \ No newline at end of file diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md deleted file mode 100644 index 5c193d7..0000000 --- a/docs/CONTRIBUTING.md +++ /dev/null @@ -1,46 +0,0 @@ -# Contributing to the Gradle Cookbook - -[![a](https://img.shields.io/badge/slack-%23docs-brightgreen?style=flat&logo=slack)](https://gradle.org/slack-invite) - - -The Gradle Cookbook is under active development. -Any contributions are welcome! - -## Discuss - -- `#docs` on the [Gradle Community Slack](https://gradle.org/slack-invite) -- [GitHub Issues](https://github.com/gradle/community/issues) - -## Development Environment - -Follow [this documentation](https://community.gradle.org/CONTRIBUTING/) for the community site. - -## HOWTOs - -### Editing and Adding Pages - -A few tips: - -- All the pages on this site are written in Markdown. -- If needed, we have various tools available, such as code templates and macros, and we can add more MkDocs plugins if necessary. -- The Table of Contents is currently located in [mkdocs.yml](https://github.com/gradle/cookbook/blob/main/mkdocs.yml). -When adding new pages, please update the ToC to ensure they are discoverable. - -### Adding New Categories - -At the moment, we add categories based on consensus. -If you plan to add a new major category, it's better to discuss it in advance. - -## Previews - -For any pull request with the approved GitHub Actions run, -a preview site will be deployed. -The build both will share the link in the comments to the pull request. - -## Building the Cookbook PDF - -Run `BUILD_PDF=1 mkdocs build` to generate the PDF file in [_site/pdf/cookbook.pdf](./../_site/pdf/cookbook.pdf). - -## References - -- [Main Contributor Guide](https://community.gradle.org/contributing/) - describes how to contribute to Gradle diff --git a/docs/android/README.md b/docs/android/README.md deleted file mode 100644 index 8ee324e..0000000 --- a/docs/android/README.md +++ /dev/null @@ -1,151 +0,0 @@ - -# Gradle for Android - -Gradle is one of the most popular build tools in the Android ecosystem. It is used for [Kotlin and Kotlin Multiplatform](../kotlin/README.md), [Flutter](https://flutter.dev/), [React Native](https://reactnative.dev/), and other toolchains. - -## Official Documentation - -The official documentation for Android development with Gradle is provided by Google and the community on the Android Developers site. You can find this documentation [here](https://developer.android.com/build). - -## Featured Recipes - -- [Gradle build overview](https://developer.android.com/build/gradle-build-overview) - Understand how Gradle builds Android applications with Gradle using Android Gradle Plugin (AGP), key concepts, and the structure of a standard Android project. - -- [Android build management](https://developer.android.com/build) - Configure your Android builds for better packaging to test, build, sign, and distribute your app bundles and APKs. - -- [Managing dependencies](https://developer.android.com/build/dependencies) - Configure remote repositories to add external binaries or other library modules into your build as dependencies. - -- [Building project](https://developer.android.com/build/building-cmdline) - Execute tasks available for Android projects using the Gradle wrapper to build and deploy APKs and app bundles. - -- [Optimizing Builds](https://developer.android.com/build/optimize-your-build) - Configure your builds to decrease the build time, resulting in faster development of your Android projects. - -- [Extending AGP](https://developer.android.com/build/extend-agp) - AGP contains extension points for plugins to control build inputs and extend its functionality through new steps that can be integrated with standard build tasks. - -- [Migration Guide](https://developer.android.com/build/migrate-to-kotlin-dsl) - Guide for migrating from Groovy to Kotlin DSL, version catalogs, Kapt (Kotlin Annotation Processing Tool) to KSP (Kotlin Symbol Processing). - -- [Troubleshooting AGP](https://developer.android.com/build/troubleshoot) - Troubleshooting guide if you encounter issues with the Android Gradle Plugin (AGP). - -## Expanded Sections - -### **1. Gradle Build Overview** -Gradle builds Android applications using the **Android Gradle Plugin (AGP)**, which provides the flexibility to define build types, product flavors, and dependencies. Understanding these key concepts is crucial for creating efficient and scalable Android projects. - -#### Key Concepts: -- **Build Variants**: Manage multiple variants of your app such as `debug` and `release`. -- **Build Types**: Use predefined types (e.g., `debug`, `release`) to control various build configurations. -- **Kotlin DSL**: Gradle uses Kotlin DSL by default for better type safety and editor support in Android builds. - -#### Example in Kotlin DSL: -```kotlin -android { - buildTypes { - release { - minifyEnabled(true) - proguardFiles( - getDefaultProguardFile("proguard-android-optimize.txt"), - "proguard-rules.pro" - ) - } - } -} -``` -For more details, visit the [Gradle build overview](https://developer.android.com/build/gradle-build-overview). - -### **2. Android Build Management** -Android build management allows you to define various configurations for packaging, testing, signing, and distributing your app. The ability to manage product flavors, build types, and dynamic delivery modules ensures flexibility across different versions of your app. - -#### Example of Build Flavors: -```kotlin -android { - flavorDimensions("version") - productFlavors { - free { - dimension = "version" - } - paid { - dimension = "version" - } - } -} -``` -For more information, visit [Android build management](https://developer.android.com/build). - -### **3. Managing Dependencies** -Gradle enables the addition of external binaries or library modules as dependencies, which is essential for maintaining large Android projects. You can also use **version catalogs** to resolve dependency version conflicts and handle dependencies in **Kotlin Multiplatform** projects. - -#### Example of Dependencies in Kotlin DSL: -```kotlin -dependencies { - implementation("com.squareup.retrofit2:retrofit:2.9.0") - implementation(platform("com.google.firebase:firebase-bom:26.7.0")) -} -``` -For more information, visit [Managing dependencies](https://developer.android.com/build/dependencies). - -### **4. Building Projects** - -Gradle provides tasks for building your Android projects, including compiling code, packaging APKs, and generating app bundles. Using the **Gradle wrapper**, you can ensure build consistency across environments. - -#### Example of Building an APK with Kotlin DSL: - -```kotlin -tasks.register("customAssembleDebug") { - doLast { - println("Building APK in debug mode...") - } -} -``` -This Kotlin example registers a task to build the APK in debug mode. For more detailed steps on building projects and packaging apps, visit the [Building Projects Guide](https://developer.android.com/build/building-cmdline). - -### **5. Optimizing Builds** -Gradle provides various options to improve build performance, including **build caching**, **parallel execution**, and **Gradle Daemon tuning**. These methods are especially beneficial for larger projects, helping to reduce build times and enhance productivity. - -#### Example of Enabling Parallel Execution: -```properties -org.gradle.parallel=true -``` - -To explore more optimization techniques and configure your builds for better performance, check out our detailed guide: [Gradle Build Optimization](./optimization.md). - -For further information, visit the **official** [Optimizing Builds Guide](https://developer.android.com/build/optimize-your-build). - -### **6. Extending AGP** -You can extend the Android Gradle Plugin (AGP) by writing custom tasks and plugins to integrate new functionality into the existing build system. This allows for advanced customization and flexibility in your build processes. - -#### Example of a Custom Task: -```kotlin -tasks.register("printHelloMessage") { - doLast { - println("Hello, Android Developers!") - } -} -``` -For more information, visit [Extending AGP](https://developer.android.com/build/extend-agp). - -### **7. Migration Guide** - -With the shift from **Groovy** to **Kotlin DSL** in the Android ecosystem, migrating your build scripts is essential. This guide helps you transition your build configurations and annotation processing from **Kapt** to **KSP**. - -For detailed steps and best practices, refer to the [official Migration Guide](https://developer.android.com/build/migrate-to-kotlin-dsl). - -### **8. Troubleshooting AGP** - -Encountering issues with the Android Gradle Plugin (AGP) is common, and this section provides solutions to common problems such as dependency resolution failures, build script errors, and performance bottlenecks. - -#### Example of Dependency Conflict Resolution: -```kotlin -configurations.all { - resolutionStrategy { - force("com.google.guava:guava:27.0.1-android") - } -} -``` -For more troubleshooting tips, visit the **official** [Troubleshooting AGP](https://developer.android.com/build/troubleshoot) page. - -You can also check the [Gradle Troubleshooting](./troubleshooting.md) page for additional help with Gradle-specific issues. - -## References - -- [Official Documentation](https://developer.android.com/build) -- [AGP releases](https://developer.android.com/build/releases/gradle-plugin) -- [Android Gradle Plugin API reference](https://developer.android.com/reference/tools/gradle-api) diff --git a/docs/android/optimization.md b/docs/android/optimization.md deleted file mode 100644 index ae8a7bc..0000000 --- a/docs/android/optimization.md +++ /dev/null @@ -1,9 +0,0 @@ -# Gradle Build Optimization - -This page references key external resources to help you optimize your Android Gradle builds. Below are some techniques and guides: - -- [Build Caching](https://developer.android.com/build/optimize-your-build#use-the-configuration-cache) – Reduce unnecessary tasks by reusing outputs from previous builds. -- [Parallel Execution](https://docs.gradle.org/current/userguide/performance.html#parallel_execution) – Execute independent tasks in parallel to speed up the build. -- [Gradle Daemon](https://docs.gradle.org/current/userguide/gradle_daemon.html#enable_deamon) – Optimize build performance by using a persistent process for faster execution. - -More original content will be added soon to cover performance monitoring, advanced caching strategies, and Gradle tuning specific to large-scale projects. diff --git a/docs/android/troubleshooting.md b/docs/android/troubleshooting.md deleted file mode 100644 index b4461da..0000000 --- a/docs/android/troubleshooting.md +++ /dev/null @@ -1,28 +0,0 @@ -# Troubleshooting Android Gradle Plugin (AGP) - -This page serves as a resource for resolving common issues encountered while working with the Android Gradle Plugin (AGP). Below are some typical problems and solutions. - -## Common Issues - -### 1. Dependency Resolution Failures -Dependency conflicts can arise when multiple libraries require different versions of the same dependency. Use the following example to enforce a specific version: - -```kotlin -configurations.all { - resolutionStrategy { - force("com.google.guava:guava:27.0.1-android") - } -} -``` - -### 2. Build Script Errors -Errors in the build script can prevent the project from compiling. Ensure that all plugins and dependencies are correctly defined. Review the logs for specific error messages that can guide you to the problem. - -### 3. Performance Bottlenecks -Build performance issues may occur due to improper configurations. To optimize your build time, consider using techniques like enabling build caching and parallel execution. - -## Additional Resources -- [Troubleshooting AGP](https://developer.android.com/build/troubleshoot) page. - -## Contributing -Feel free to add additional tips or common issues you encounter. Contributions are welcome to improve this troubleshooting guide. diff --git a/docs/assets/css/gradle.css b/docs/assets/css/gradle.css deleted file mode 100644 index cba19a4..0000000 --- a/docs/assets/css/gradle.css +++ /dev/null @@ -1,168 +0,0 @@ - -/* TODO: proper styling */ -:root { - /* https://gradle.com/brand/ */ - --gradle-bg-dark: #010002; - --gradle-bg-gray: #F8F8F8; - --gradle-bg-white: #FFFFFF; - --gradle-blue: #209BC4; - --gradle-blue-lite: #4DC9C0; - - - --md-primary-fg-color: var(--gradle-bg-dark); - --md-primary-fg-color--light: var(--gradle-bg-gray); - --md-primary-fg-color--dark: var(--gradle-bg-dark); -} - -.md-banner { - div { - text-align: center; - a { - color: var(--gradle-blue); - font-weight: bold; - } - } -} - -.md-content { - --md-typeset-a-color: var(--gradle-blue); -} - -/* -.md-nav__item--section>.md-nav__link[for] { - color: var(--gradle-blue-lite); -}*/ - -.md-nav__link--active > span { - color: var(--gradle-blue); - font-weight: bold; -} - -.md-typeset h1 { - color: var(--gradle-dark); -} - -h2 { - color: var(--gradle-dark); -} - -h3 { - color: var(--gradle-dark); -} - -h4 { - color: var(--gradle-dark); -} - -.youtube-video { - overflow: hidden; - position: relative; - display: flex; - justify-content: center; - - div { - position: relative; - height: 100%; - width: 100%; - aspect-ratio: 16/9; - max-width: 900px; - } - - iframe { - width: 70%; - aspect-ratio: 16 / 9; - } - - @media (max-width: 1200px) { - iframe { - width: 100%; - } - } -} - -.grid-container { - display: flex; - flex-wrap: wrap; - margin-left: auto; - margin-right: auto; - gap: 1rem; - vertical-align: middle; - - .card { - display: block; - border: .2rem solid; - border-radius: 1rem; - padding: 1rem; - align-items: center; - width: 48%; - min-width: 320px; - - h3 { - font-size: x-large; - font-weight: bolder; - span { - margin-right: 0.5rem; - .section-icon { - width: 20px; - height: 20px; - } - } - } - - items { - font-size: larger; - font-weight: bold; - } - } -} - -.button { - display: inline-block; - min-width: 180px; - padding: 10px 20px; - font-size: 17px; - line-height: 1.4; - text-align: center; - font-size: large; - font-weight: bold; - white-space: nowrap; - cursor: pointer; - border-style: solid; - border-width: 1px; - border-radius: 8px; - transition: background-color .3s ease, border .3s ease; -} - -.icon { - width: 20px; -} - -.button--blue, -.button--blue-lite { - color: white; - border-color: transparent; - &:hover { - color: white; - } -} - - -.button--blue { - border-color: var(--gradle-blue-lite); - background: var(--gradle-blue); - background: linear-gradient(var(--button-gradient-angle), var(--gradle-blue) 0%, var(--gradle-blue-lite) 100%); - transition: none; - &:hover { - background-color: var(--gradle-blue-lite); - color: white; - } -} - - -.button--blue-lite { - background-color: var(--gradle-bg-gray); - &:hover { - background-color: var(--gradle-blue-lite); - color: white; - } -} diff --git a/docs/assets/images/logos/gradle-build-tool.svg b/docs/assets/images/logos/gradle-build-tool.svg deleted file mode 100644 index fe4f071..0000000 --- a/docs/assets/images/logos/gradle-build-tool.svg +++ /dev/null @@ -1,2 +0,0 @@ - - \ No newline at end of file diff --git a/docs/assets/images/logos/gradle.svg b/docs/assets/images/logos/gradle.svg deleted file mode 100644 index c114d26..0000000 --- a/docs/assets/images/logos/gradle.svg +++ /dev/null @@ -1,23 +0,0 @@ - - - - - - - - - - - - - - diff --git a/docs/chapters.md b/docs/chapters.md deleted file mode 100644 index 5ffc963..0000000 --- a/docs/chapters.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: Gradle Cookbook Chapters ---- - -Below, you can see the list of the chapters -that are currently available on the cookbook. -More chapters will be added soon, contributions are [welcome](./CONTRIBUTING.md)!. - -## Integrations - -- [Maven Central Publishing](./integrations/maven-central/publishing.md) -- [Gradle on Continuous Integration](./ci/README.md) - -## By Technology - -- [Gradle for Kotlin development](./kotlin/README.md) -- [Gradle for Android development](./android/README.md) - - -## For Developers - -- [Troubleshooting Gradle issues and performance](./troubleshooting/README.md) -- [Plugin Development](./plugin-development/README.md) diff --git a/docs/ci/README.md b/docs/ci/README.md deleted file mode 100644 index db95768..0000000 --- a/docs/ci/README.md +++ /dev/null @@ -1,23 +0,0 @@ -# Using Gradle with Continuous Integration Systems - -Gradle has many integrations with Continuous Integration (CI) -and Continuous Delivery (CD) systems. -Below you can find references to integrations and best practices. - -!!! warning - This section is under active development. - The pages might be outdated, contributions are welcome! - -## Recipes - -- [GitHub Actions](./github-actions.md) -- [GitLab CI](./gitlab-ci.md) -- [Jenkins](jenkins.md) -- [TeamCity](./teamcity.md) -- [Travis CI](./travis-ci.md) - -## External Pages - -- [Tekton task for Gradle](https://hub.tekton.dev/tekton/task/gradle) -- [CircleCI orb for Gradle](https://circleci.com/developer/orbs/orb/circleci/gradle) - diff --git a/docs/ci/github-actions.md b/docs/ci/github-actions.md deleted file mode 100644 index bd79481..0000000 --- a/docs/ci/github-actions.md +++ /dev/null @@ -1,198 +0,0 @@ -# Executing Gradle builds on GitHub Actions - -!!! tip - Top engineering teams using GitHub Actions have been able to reduce CI build time by up to 90% by using the Gradle Build Cache. [Register here](https://dpeuniversity.gradle.com/app/courses/ec69d0b8-9171-4969-ac3e-82dea16f87b0) for our Build Cache training session to learn how your team can achieve similar results. - -Building Gradle projects doesn't stop with the developer's machine. [Continuous Integration](https://en.wikipedia.org/wiki/Continuous_integration) (CI) has been a long-established practice for running a build for every single change committed to version control to tighten the feedback loop. - -In this guide, we'll discuss how to configure [GitHub Actions](https://github.com/features/actions/) for a Gradle project hosted on GitHub. - -## Introduction - -GitHub Actions is a cloud-based CI solution provider built directly into GitHub, making it an excellent choice for projects hosted on GitHub. Using the [setup-gradle](https://github.com/gradle/actions/tree/main/setup-gradle) GitHub Action makes it simple to integrate any Gradle project into a GitHub Actions workflow. - -## What you'll need - -* A text editor -* A command prompt -* The Java Development Kit (JDK), version 1.8 or higher -* A local Gradle installation, to initialize a new Gradle project -* A GitHub account - -## Setup a Gradle project on GitHub - -If you have an existing Gradle project hosted on GitHub, then you can skip this step and move directly to [Configure GitHub Actions](#configure-github-actions). - -If not, follow these steps to initialize a new Gradle project on GitHub. - -### Create a new GitHub repository for your project - -Via the GitHub user interface, create a new repository named `github-actions-gradle-sample`. - -![Create new GitHub repository](images/github-actions-create-repository.png) - -### Clone the repository locally - -```shell -$ git clone git@github.com:/github-actions-gradle-sample.git -Cloning into 'github-actions-gradle-sample'... -$ cd github-actions-gradle-sample -``` - -### Initialize the Gradle project and commit to the repository - -Use `gradle init` to create a fresh Gradle project. You can choose any of the available options during `init`, but we recommend choosing "library" as the project type. - -Once the project is generated, commit the changes and push to the repository. - -```shell -$ gradle init -$ git add . -$ git commit -m "Initial commit" -$ git push -``` - -### Test building the project - -The project uses the [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html) for building the project. It is a recommended practice for any Gradle project as it enables your project to be built on CI without having to install the Gradle runtime. - -Before asking GitHub Actions to build your project, it's useful to ensure that it builds locally. Adding the "CI" environment variable will emulate running the build on GitHub Actions. - -The following command achieves that: - -```shell -$ CI=true ./gradlew build - -BUILD SUCCESSFUL -``` - -If the build works as expected, we are ready to build it with GitHub Actions. - -## Configure GitHub Actions - -You can create a GitHub Actions workflow by adding a `.github/workflows/.yml` file to your repository. This workflow definition file contains all relevant instructions for building the project on GitHub Actions. - -The following workflow file instructs GitHub Actions to build your Gradle project using the Gradle Wrapper, executed by the default Java distribution for GitHub Actions. Create a new file named `.github/workflows/build-gradle-project.yml` with the following content, and push it to the GitHub repository. - -```yaml -name: Build Gradle project - -on: - push: - -jobs: - build-gradle-project: - runs-on: ubuntu-latest - steps: - - name: Checkout project sources - uses: actions/checkout@v4 - - - name: Setup Gradle - uses: gradle/actions/setup-gradle@v3 - with: - build-scan-publish: true - build-scan-terms-of-use-url: "https://gradle.com/terms-of-service" - build-scan-terms-of-use-agree: "yes" - - - name: Run build - run: ./gradlew build -``` - -[Gradle Build Scans®](https://scans.gradle.com) are a great way to view your build results and provide valuable insights into your build. The workflow is configured to automatically publish a Build Scan for each build, accepting the legal terms of use. If you don't wish to publish Build Scans, you can remove this configuration from the workflow. - -Commit the changes and push to the repository: - -```shell -$ git add . -$ git commit -m "Add GitHub Actions workflow" -$ git push -``` - -## View the GitHub Actions results - -Once this workflow file is pushed, you should immediately see the workflow execution in the GitHub Actions page for your repository (e.g., https://github.com/gradle/gradle/actions). Any subsequent push to the repository will trigger the workflow to run. - -### List all runs of the GitHub Actions workflow - -The main actions page can be used to list all runs for a GitHub Actions workflow. - -![View workflow executions](images/github-actions-workflows.png) - -### See the results for GitHub Actions workflow run - -Clicking on the link for a workflow run will show the details of the workflow run, including a summary of all Gradle builds with links to any Build Scan published. - -**TIP:** Configuring [build scans](https://scans.gradle.com) is especially helpful on cloud CI systems like GitHub Actions because it has additional environment and test results information that are difficult to obtain otherwise. - -![View workflow execution details](images/github-actions-workflow.png) - -### View the details for Jobs and Steps in the workflow - -Finally, you can view the logs for the individual workflow Jobs and each Step defined for a Job: - -![View workflow job details](images/github-actions-job-details.png) - -## Enable caching of downloaded artifacts - -The [setup-gradle](https://github.com/gradle/actions/tree/main/setup-gradle) action used by this workflow will enable saving and restoring of the Gradle User Home directory in the built-in GitHub Actions cache. This will speed up your GitHub Actions build by avoiding the need to re-download Gradle versions and project dependencies, as well as re-using state from the previous workflow execution. - -Details about what entries are saved/restored from the cache can be viewed in the generated Job Summary: - -![View cache entry details](images/github-actions-cache-details.png) - -## Detect vulnerable dependencies with a dependency-submission workflow - -[GitHub supply chain security](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-supply-chain-security) features will detect and alert about any dependencies that have known vulnerabilities. In order to do this, GitHub requires a complete dependency graph for your project. - -**NOTE:** Ensure that you have both [Dependency graph](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/configuring-the-dependency-graph) and [Dependabot alerts](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/configuring-dependabot-alerts#managing-dependabot-alerts-for-your-repository) enabled for your repository. - -The [dependency-submission](https://github.com/gradle/actions/tree/main/dependency-submission) action for Gradle provides the simplest way to generate a dependency graph for your project. This action will attempt to detect and upload a list of all dependencies used by your build. - -We recommend a separate GitHub Actions workflow for dependency submission. Create a GitHub Actions workflow by adding a `.github/workflows/.yml` file to your repository. Create a new file named `.github/workflows/gradle-dependency-submission.yml` with the following content, and push it to the GitHub repository. - -```yaml -name: Gradle Dependency Submission - -on: - push: - branches: - - main - -jobs: - dependency-submission: - runs-on: ubuntu-latest - steps: - - name: Checkout project sources - uses: actions/checkout@v4 - - - name: Generate and submit dependency graph - uses: gradle/actions/dependency-submission@v3 - with: - build-scan-publish: true - build-scan-terms-of-use-url: "https://gradle.com/terms-of-service" - build-scan-terms-of-use-agree: "yes" -``` - -[Gradle Build Scans®](https://scans.gradle.com) are a great way to view your build results and provide valuable insights into your build. The workflow is configured to automatically publish a Build Scan for each build, accepting the legal terms of use. If you don't wish to publish Build Scans, you can remove this configuration from the workflow. - -Commit the changes and push to the repository: - -```shell -$ git add . -$ git commit -m "Add Dependency submission workflow" -$ git push -``` - -### Viewing the dependency graph - -Once the dependency-submission workflow has completed, you can view all reported dependencies by navigating to `Insights -> Dependency graph`. - -This image reveals that the repository contains a version of `com.google.guava:guava` with a moderate vulnerability. - -![View dependency graph](images/github-actions-dependency-graph.png) - -### Viewing all dependency alerts - -You can view a list of all vulnerabilities by navigating to `Security -> Dependabot`. - -![View dependency alerts](images/github-actions-dependency-alerts.png) diff --git a/docs/ci/gitlab-ci.md b/docs/ci/gitlab-ci.md deleted file mode 100644 index f171228..0000000 --- a/docs/ci/gitlab-ci.md +++ /dev/null @@ -1,189 +0,0 @@ -# Executing Gradle builds on GitLab CI - -!!! tip - Top engineering teams using GitLab CI have been able to reduce CI build time by up to 90% by using the Gradle Build Cache. https://gradle.org/training/#build-cache-deep-dive[Register here] for our Build Cache training session to learn how your team can achieve similar results. - -Building Gradle projects doesn't stop with the developer's machine. -https://en.wikipedia.org/wiki/Continuous_integration[Continuous Integration] (CI) has been a long-established practice for running a build for every single change committed to version control to tighten the feedback loop. - -In this guide, we'll discuss how to configure link:https://docs.gitlab.com/ee/ci/[GitLab CI] for a Gradle project hosted on GitLab (GitLab.com, self-managed or dedicated). - -## Introduction - -GitLab CI is a cloud-based CI solution provider built directly into GitLab, making it an excellent choice for projects hosted on GitLab. - -## What you'll need - -* A text editor -* A command prompt -* The Java Development Kit (JDK), version 1.8 or higher -* A local Gradle installation to initialize a new Gradle project -* A GitLab instance (any tier, any deployment type) -* A GitLab account on the instance you want to use - -## Setup a Gradle project on GitLab - -If you have a Gradle project hosted on GitLab, you can skip this step and move directly to [Configure GitLab CI](.#configure-gitlab-ci) - -If not, follow these steps to initialize a new Gradle project on GitLab. - -### Create a new GitLab repository for your project - -Create a new repository named `gitlab-ci-gradle-sample` via the GitLab user interface. - -![Create new GitHub repository](images/gitlab-ci-create-repository.png) - -### Clone the repository locally - -```shell -$ git clone git@example.gitlab.com:/gitlab-ci-gradle-sample.git -Cloning into 'gitlab-ci-gradle-sample'... -$ cd gitlab-ci-gradle-sample -``` - -### Initialize the Gradle project and commit to the repository - -Use `gradle init` to create a fresh Gradle project. You can choose any available options during `init`, but we recommend choosing "library" as the project type. - -Once the project is generated, commit the changes and push to the repository. - -```shell -$ gradle init -$ git add . -$ git commit -m "Initial commit" -$ git push -``` - -### Enable Build Scan™ publishing - -[Gradle Build Scans](https://scans.gradle.com) are a great way to view your build results and provide valuable insights into your build. -To publish Build Scans from GitLab CI, you'll need to pre-approve the Terms & Conditions. - -To do so, add the following content to the top of your `settings.gradle[.kts]` file. GitLab CI sets the "CI" environment variable: - -```groovy -plugins { - id("com.gradle.enterprise") version("3.16.2") -} - -gradleEnterprise { - if (System.getenv("CI") != null) { - buildScan { - publishAlways() - termsOfServiceUrl = "https://gradle.com/terms-of-service" - termsOfServiceAgree = "yes" - } - } -} -``` - -### Test building the project - -The project uses the Gradle Wrapper for building the project. -It is a recommended practice for any Gradle project as it enables your project to build on CI without installing the Gradle runtime. - -Before asking GitLab CI to build your project, it's useful to ensure that it builds locally. -Adding the "CI" environment variable will emulate running the build on GitLab CI. - -The following command achieves that: - -```shell -$ CI=true ./gradlew build - -BUILD SUCCESSFUL - -Publishing build scan... -https://gradle.com/s/7mtynxxmesdio -``` - -If the build works as expected, commit the changes and push to the repository. - - -```shell -$ git commit -a -m "Publish Build Scans from GitLab CI" -$ git push -``` - -## Configure GitLab CI - -You can create a GitLab CI pipeline by adding a `.gitlab-ci.yml` file to your repository. -This pipeline definition file contains all relevant instructions for building the project on Gitlab CI. - -The following workflow file instructs GitLab CI to build your Gradle project using the Gradle Wrapper, executed by the Eclipse Temurin JDK. -Create a new file named `.gitlab-ci.yml` with the following content, and push it to the GitLab repository. - -```yaml -build-gradle-project: - image: eclipse-temurin:latest - - script: - - ./gradlew build - - artifacts: - reports: - junit: '**/build/test-results/**/TEST-*.xml' -``` - -This file defines a single job that executes the `./gradlew build` command. - -* The `image` field defines which Docker image the job will run in. Thanks to the Gradle Wrapper, only a JDK is necessary. -* The `artifacts` field defines files generated by the job that GitLab CI should save. In particular, saving the JUnit report generated by the Gradle test tasks allows test results to be displayed directly in the Merge Request or Pipeline pages. - -Commit the changes and push them to the repository: - -```shell -$ git add . -$ git commit -m "Add GitLab CI pipeline" -$ git push -``` - -## View the GitLab CI results - -Once this pipeline file is pushed, you should immediately see the pipeline execution in the GitLab CI page for your repository (e.g., `https://gitlab.com/username/repository/-/pipelines`). -Any subsequent push to the repository will trigger the pipeline to run. - -## Enable caching - -By default, no files are persisted between CI runs, so each job must download all dependencies again. We can configure GitLab to cache some files between jobs. This is especially efficient when running your own GitLab CI runner, as the cache is stored locally on the runner. - -CAUTION: The publicly available shared runners store their cache in a remote location. As the cache grows, downloading the cache archive, extracting it, and uploading it again at the end of the job may take more time than not using any cache. For this reason, we recommend only caching the Gradle Wrapper. For caching of intermediate build results, see configuring a [Gradle Remote Build Cache](https://docs.gradle.org/current/userguide/build_cache.html). To cache external dependencies used in builds, it is best to set up a dedicated repository manager in your infrastructure and configure it as a proxy for those dependencies. Solutions like [Sonatype Nexus](https://hub.docker.com/r/sonatype/nexus3/) or [JFrog Artifactory](https://jfrog.com/) can be used to act as a repository manager. - -To reuse some files between jobs, add the following configuration to your existing jobs: - -```yaml -build-gradle-project: - # …existing configuration… - - variables: - GRADLE_USER_HOME: $CI_PROJECT_DIR/.gradle - - cache: - paths: - - .gradle/wrapper - key: - files: - - gradle/wrapper/gradle-wrapper.properties -``` - -Commit the changes and push to the repository: - -```shell -$ git add . -$ git commit -m "Cache the Gradle Wrapper between CI jobs" -$ git push -``` - -## Further reading - -Learn more about building Gradle projects with GitLab CI: - -* [GitLab CI documentation](https://docs.gitlab.com/ee/ci/) -* [.gitlab-ci.yml syntax reference](https://docs.gitlab.com/ee/ci/yaml/) -* [Predefined variables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) -* [Avoiding duplication between multiple jobs](https://docs.gitlab.com/ee/ci/yaml/yaml_optimization.html) - -## Summary - -Setting up and configuring Gradle builds on CI is straightforward, requiring just a few steps. -The benefit of receiving fast feedback clearly speaks for itself. -GitLab CI offers a simple and convenient mechanism to set up CI for any Gradle project hosted on GitLab. diff --git a/docs/ci/images/github-actions-cache-details.png b/docs/ci/images/github-actions-cache-details.png deleted file mode 100644 index 537f71c..0000000 Binary files a/docs/ci/images/github-actions-cache-details.png and /dev/null differ diff --git a/docs/ci/images/github-actions-create-repository.png b/docs/ci/images/github-actions-create-repository.png deleted file mode 100644 index c6c24e6..0000000 Binary files a/docs/ci/images/github-actions-create-repository.png and /dev/null differ diff --git a/docs/ci/images/github-actions-dependency-alerts.png b/docs/ci/images/github-actions-dependency-alerts.png deleted file mode 100644 index 5fc435e..0000000 Binary files a/docs/ci/images/github-actions-dependency-alerts.png and /dev/null differ diff --git a/docs/ci/images/github-actions-dependency-graph.png b/docs/ci/images/github-actions-dependency-graph.png deleted file mode 100644 index dd69bc9..0000000 Binary files a/docs/ci/images/github-actions-dependency-graph.png and /dev/null differ diff --git a/docs/ci/images/github-actions-job-details.png b/docs/ci/images/github-actions-job-details.png deleted file mode 100644 index c14e21d..0000000 Binary files a/docs/ci/images/github-actions-job-details.png and /dev/null differ diff --git a/docs/ci/images/github-actions-workflow.png b/docs/ci/images/github-actions-workflow.png deleted file mode 100644 index f45ed92..0000000 Binary files a/docs/ci/images/github-actions-workflow.png and /dev/null differ diff --git a/docs/ci/images/github-actions-workflows.png b/docs/ci/images/github-actions-workflows.png deleted file mode 100644 index b92bed8..0000000 Binary files a/docs/ci/images/github-actions-workflows.png and /dev/null differ diff --git a/docs/ci/images/gitlab-ci-create-repository.png b/docs/ci/images/gitlab-ci-create-repository.png deleted file mode 100644 index cbe3667..0000000 Binary files a/docs/ci/images/gitlab-ci-create-repository.png and /dev/null differ diff --git a/docs/ci/images/jenkins-build-scan.png b/docs/ci/images/jenkins-build-scan.png deleted file mode 100644 index d548b6c..0000000 Binary files a/docs/ci/images/jenkins-build-scan.png and /dev/null differ diff --git a/docs/ci/images/jenkins-build-step.png b/docs/ci/images/jenkins-build-step.png deleted file mode 100644 index 4efc09b..0000000 Binary files a/docs/ci/images/jenkins-build-step.png and /dev/null differ diff --git a/docs/ci/images/jenkins-scm.png b/docs/ci/images/jenkins-scm.png deleted file mode 100644 index 16d15c4..0000000 Binary files a/docs/ci/images/jenkins-scm.png and /dev/null differ diff --git a/docs/ci/images/teamcity-build-scan-plugin.png b/docs/ci/images/teamcity-build-scan-plugin.png deleted file mode 100644 index 516d9df..0000000 Binary files a/docs/ci/images/teamcity-build-scan-plugin.png and /dev/null differ diff --git a/docs/ci/images/teamcity-build-step.png b/docs/ci/images/teamcity-build-step.png deleted file mode 100644 index e8fd0e1..0000000 Binary files a/docs/ci/images/teamcity-build-step.png and /dev/null differ diff --git a/docs/ci/images/teamcity-create-project.png b/docs/ci/images/teamcity-create-project.png deleted file mode 100644 index fb89cac..0000000 Binary files a/docs/ci/images/teamcity-create-project.png and /dev/null differ diff --git a/docs/ci/images/teamcity-log-link.png b/docs/ci/images/teamcity-log-link.png deleted file mode 100644 index 9083974..0000000 Binary files a/docs/ci/images/teamcity-log-link.png and /dev/null differ diff --git a/docs/ci/images/teamcity-results.png b/docs/ci/images/teamcity-results.png deleted file mode 100644 index 68608a8..0000000 Binary files a/docs/ci/images/teamcity-results.png and /dev/null differ diff --git a/docs/ci/images/teamcity-scan.png b/docs/ci/images/teamcity-scan.png deleted file mode 100644 index bc4e49f..0000000 Binary files a/docs/ci/images/teamcity-scan.png and /dev/null differ diff --git a/docs/ci/images/teamcity-step-added.png b/docs/ci/images/teamcity-step-added.png deleted file mode 100644 index 763ba78..0000000 Binary files a/docs/ci/images/teamcity-step-added.png and /dev/null differ diff --git a/docs/ci/images/teamcity-step-upd.png b/docs/ci/images/teamcity-step-upd.png deleted file mode 100644 index 7c31be7..0000000 Binary files a/docs/ci/images/teamcity-step-upd.png and /dev/null differ diff --git a/docs/ci/images/teamcity-tests.png b/docs/ci/images/teamcity-tests.png deleted file mode 100644 index a975d53..0000000 Binary files a/docs/ci/images/teamcity-tests.png and /dev/null differ diff --git a/docs/ci/images/travis-enable-project.png b/docs/ci/images/travis-enable-project.png deleted file mode 100644 index 36e1610..0000000 Binary files a/docs/ci/images/travis-enable-project.png and /dev/null differ diff --git a/docs/ci/jenkins.md b/docs/ci/jenkins.md deleted file mode 100644 index 621dd84..0000000 --- a/docs/ci/jenkins.md +++ /dev/null @@ -1,111 +0,0 @@ -# Executing Gradle builds on Jenkins - -!!! tip - Top engineering teams using Jenkins have been able to reduce CI build time by up to 90% by using the Gradle Build Cache. [Register here](https://dpeuniversity.gradle.com/app/courses/ec69d0b8-9171-4969-ac3e-82dea16f87b0) for our Build Cache training session to learn how your team can achieve similar results. - -Building Gradle projects doesn't stop with the developer's machine. [Continuous Integration](https://en.wikipedia.org/wiki/Continuous_integration) (CI) has been a long-established practice for running a build for every single change committed to version control to tighten the feedback loop. - -In this guide, we'll discuss how to configure [Jenkins](https://jenkins.io/) for a typical Gradle project. - -## What you'll need - -- A text editor -- A command prompt -- The Java Development Kit (JDK), version 1.7 or higher -- A Jenkins installation (setup steps explained in this post) - -## Setup a typical project - -As an example, this guide is going to focus on a Java-based project. More specifically, a Gradle plugin written in Java and tested with [Spek](https://www.spekframework.org/). First, we'll get the project set up on your local machine before covering the same steps on CI. - -Just follow these steps: - -### Clone the [Gradle Site Plugin](https://github.com/gradle/gradle-site-plugin) repository - -```bash -$ git clone https://github.com/gradle/gradle-site-plugin.git -Cloning into 'gradle-site-plugin'... -$ cd gradle-site-plugin -``` - -### Build the project - -As a developer of a Java project, you'll typically want to compile the source code, run the tests, and assemble the JAR artifact. That's no different for Gradle plugins. The following command achieves exactly that: - -```bash -$ ./gradlew build - -BUILD SUCCESSFUL -14 actionable tasks: 14 executed -``` - -The project provides the [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html) as part of the repository. It is a recommended practice for any Gradle project as it enables your project to be built on CI without having to install the Gradle runtime. - -### Build scan integration - -The sample project is equipped with support for generating [build scans](https://scans.gradle.com/). Running the build with the command line option `--scan` renders a link in the console. - -```bash -$ ./gradlew build --scan - -Publishing build scan... -https://gradle.com/s/7mtynxxmesdio -``` - -The following section will describe how to build the project with the help of Jenkins. - -## Setup Jenkins - -Jenkins is one of the most prominent players in the field. In the course of this section, you'll learn how to set up Jenkins, configure a job to pull the source code from GitHub, and run the Gradle build. - -### Install and start Jenkins - -On the [Jenkins website](https://jenkins.io/download/), you can pick from a variety of distributions. This post uses the runnable WAR file. A simple Java command brings up the Jenkins server. - -```bash -$ wget https://mirrors.jenkins.io/war-stable/latest/jenkins.war -$ java -jar jenkins.war -``` - -In the browser, navigate to `localhost` with port `8080` to render the Jenkins dashboard. You will be asked to set up a new administration user and which plugins to install. - -### Installation of plugins - -Confirm to install the recommended plugins when starting Jenkins for the first time. Under "Manage Jenkins > Manage Plugins," ensure that you have the following two plugins installed: - -- [Git plugin](https://plugins.jenkins.io/git) -- [Gradle plugin](https://plugins.jenkins.io/gradle) - -Next, we can set up the job for building the project. - -## Create a Jenkins job - -Setting up a new Gradle job can be achieved with just a couple of clicks. From the left navigation bar, select "New Item > Freestyle project". Enter a new name for the project. We'll pick "gradle-site-plugin" for the project. - -Select the radio button "Git" in the section "Source Code Management". Enter the URL of the GitHub repository: `https://github.com/gradle/gradle-site-plugin.git`. - -![Source Code Management](images/jenkins-scm.png) - -Furthermore, create a "Build step" in the section "Build" by selecting "Invoke Gradle script". As mentioned before, we'll want to use the Wrapper to execute the build. In the "Tasks" input box, enter `build` and use the "Switches" `--scan -s` to generate a build scan and render a stack trace in case of a build failure. - -![Build Step](images/jenkins-build-step.png) - -### Execute the job - -Save the configuration of the job and execute an initial build by triggering the "Build Now" button. The build should finish successfully and render a "Gradle Build Scan" icon that brings you directly to the [build scan](https://scans.gradle.com) for the given build. - -![Build Scan](images/jenkins-build-scan.png) - -There are various options to trigger Jenkins builds continuously: from polling the repository periodically, to building on a set schedule, or via callback URL. - -## Further reading - -You can learn more about advanced Jenkins usage through these resources: - -- [Using credentials with Jenkins](https://jenkins.io/doc/book/using/using-credentials/) -- [Pipeline as code with Jenkins](https://jenkins.io/solutions/pipeline/) -- [Modeling a Continuous Deployment pipeline for a Spring Boot application](https://bmuschko.com/blog/jenkins-build-pipeline/) - -## Summary - -Executing Gradle builds on CI can be set up and configured with just a handful of steps. The benefit of receiving fast feedback clearly speaks for itself. If you are not using Jenkins, no problem, many CI products tightly integrate with Gradle as a first-class citizen. \ No newline at end of file diff --git a/docs/ci/teamcity.md b/docs/ci/teamcity.md deleted file mode 100644 index 3b7493b..0000000 --- a/docs/ci/teamcity.md +++ /dev/null @@ -1,137 +0,0 @@ -# Executing Gradle builds on TeamCity - -!!! tip - Top engineering teams using TeamCity have been able to reduce CI build time by up to 90% by using the Gradle Build Cache. [Register here](https://dpeuniversity.gradle.com/app/courses/ec69d0b8-9171-4969-ac3e-82dea16f87b0) for our Build Cache training session to learn how your team can achieve similar results. - -Building Gradle projects doesn't stop with the developer's machine. [Continuous Integration](https://en.wikipedia.org/wiki/Continuous_integration) (CI) has been a long-established practice for running a build for every single change committed to version control to tighten the feedback loop. - -In this guide, we'll discuss how to configure [TeamCity](https://www.jetbrains.com/teamcity/) for a typical Gradle project. - -## What you'll need - -- A command prompt -- The Java Development Kit (JDK), version 1.8 or higher -- A TeamCity installation (setup steps explained in this guide) - -## Setup a typical project - -For demonstration purposes, this guide is going to focus on building a Java-based project; however, this setup will work with any Gradle-compatible project. More specifically, a Gradle plugin written in Java and tested with [Spek](https://www.spekframework.org/). First, we'll get the project set up on your local machine before covering the same steps on CI. - -Just follow these steps: - -### Clone the [Gradle Site Plugin](https://github.com/gradle/gradle-site-plugin) repository - -```bash -$ git clone https://github.com/gradle/gradle-site-plugin.git -Cloning into 'gradle-site-plugin'... -$ cd gradle-site-plugin -``` - -### Build the project - -As a developer of a Java project, you'll typically want to compile the source code, run the tests, and assemble the JAR artifact. That's no different for Gradle plugins. The following command achieves exactly that: - -```bash -$ ./gradlew build - -BUILD SUCCESSFUL -14 actionable tasks: 14 executed -``` - -The project provides the [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html) as part of the repository. It is a recommended practice for any Gradle project as it enables your project to be built on CI without having to install the Gradle runtime. - -### Build scan integration - -The sample project is equipped with support for generating [build scans](https://scans.gradle.com/). Running the build with the command line option `--scan` renders a link in the console. - -```bash -$ ./gradlew build --scan -Publishing build scan... -https://gradle.com/s/7mtynxxmesdio -``` - -## Setup TeamCity - -JetBrains TeamCity is a powerful and user-friendly Continuous Integration and Deployment server that works out of the box. JetBrains offers several licensing options that allow you to scale TeamCity to your needs. In this setup, we'll use TeamCity Professional, a free fully functional edition suitable for average projects. In the course of this section, you'll learn how to set up TeamCity, create a build configuration to pull the source code from GitHub, and run the Gradle build. - -### Install and start TeamCity - -On the [TeamCity website](https://www.jetbrains.com/teamcity/download/), you can pick from a variety of distributions. This post uses TeamCity bundled with Tomcat servlet container and covers the evaluation setup of a TeamCity server and a default build agent running on the same machine. - -1. Make sure you have JRE or JDK installed and the JAVA_HOME environment variable is pointing to the Java installation directory. Oracle Java 1.8 JDK is required. -2. Download TeamCity .tar.gz distribution. Unpack the `TeamCity.tar.gz` archive, for example, using the WinZip, WinRar or a similar utility under Windows, or the following command under Linux or macOS: - - ```bash - tar xfz TeamCity.tar.gz - ``` - -3. Start the TeamCity server and one default agent at the same time, using the runAll script provided in the `/bin` directory, e.g. - - ```bash - runAll.sh start - ``` - -4. To access the TeamCity Web UI, navigate to `http://localhost:8111/`. Follow the defaults of the TeamCity setup. You will be asked to set up a new administration user. - -Next, we can set up the project and run a build in TeamCity. - -## Create a TeamCity build - -Setting up a new Gradle build in TeamCity requires just a few clicks: TeamCity comes bundled with a Gradle plugin, so you do not need to install plugins additionally. However, it is recommended that you install the [TeamCity Build Scan plugin](https://plugins.jetbrains.com/plugin/9326-gradle-build-scan-integration). - -On the **Administration | Projects** page click _Create project_, use the option _From the repository URL_ and enter the URL of the GitHub repository: `https://github.com/gradle/gradle-site-plugin.git`. - -![Source Code Management](images/teamcity-create-project.png) - -Follow the _Create Project_ wizard, it will prompt for the project and build configuration name and automatically detect build steps. Select the automatically Gradle build step and click _Use selected_: - -![Build Step](images/teamcity-build-step.png) - -The build step is added to the build configuration: - -![Step Added](images/teamcity-step-added.png) - -Click _Edit_, on the page that opens click _Advanced options_. Using the Wrapper to execute the build is considered good practice with Gradle, and on automatic detection, this option is selected by default. We’ll want to generate a build scan, so we’ll enter the `--scan` option in _Additional Gradle command line parameters_ field. - -![Scan Option](images/teamcity-scan.png) - -Save the settings and we’re ready to run the build. - -### Run the build in TeamCity - -Click the _Run_ button in the top right corner: - -![Run Build](images/teamcity-step-upd.png) - -TeamCity will start the build and you’ll be able to view the build progress by clicking _Build Configuration Home_. When the build is finished, you can review the build results by clicking the build number link: - -![Build Results](images/teamcity-results.png) - -You can view the tests right here in TeamCity: - -![Tests](images/teamcity-tests.png) - -The information on parameters and environment of the build is available on the _Parameters_ tab of the build results. - -If you installed the [TeamCity Build Scan plugin](https://plugins.jetbrains.com/plugin/9326-gradle-build-scan-integration), you will see a link to the build scan in the Build Results view: - -![Build Scan Plugin](images/teamcity-build-scan-plugin.png) - -Otherwise, the link to the [build scan](https://scans.gradle.com) for the given build is available in the build log: - -![Build Log Link](images/teamcity-log-link.png) - -There are various options to trigger TeamCity builds continuously: from [polling the repository](https://www.jetbrains.com/help/teamcity/configuring-build-triggers.html) periodically, to [building on a set schedule](https://www.jetbrains.com/help/teamcity/configuring-schedule-triggers.html), or via [post-commit hook](https://www.jetbrains.com/help/teamcity/configuring-vcs-post-commit-hooks-for-teamcity.html). - -## Further reading - -You can learn more about advanced TeamCity usage through these resources: - -- [Build chains and dependencies](https://www.jetbrains.com/help/teamcity/build-dependencies-setup.html) -- [Remote run and pre-tested commit](https://www.jetbrains.com/help/teamcity/pre-tested-delayed-commit.html) - -More information is available in [TeamCity documentation](https://www.jetbrains.com/help/teamcity/teamcity-documentation.html). Follow the [TeamCity blog](https://blog.jetbrains.com/teamcity/) for the latest news. - -## Summary - -Executing Gradle builds on CI can be set up and configured with just a handful of steps. The benefit of receiving fast feedback clearly speaks for itself. If you are not using TeamCity, no problem, many CI products tightly integrate with Gradle as a first-class citizen. \ No newline at end of file diff --git a/docs/ci/travis-ci.md b/docs/ci/travis-ci.md deleted file mode 100644 index 30eaeeb..0000000 --- a/docs/ci/travis-ci.md +++ /dev/null @@ -1,107 +0,0 @@ -# Executing Gradle builds on Travis CI - -!!! tip - Top engineering teams using Travis CI have been able to reduce CI build time by up to 90% by using the Gradle Build Cache. [Register here](https://dpeuniversity.gradle.com/app/courses/ec69d0b8-9171-4969-ac3e-82dea16f87b0) for our Build Cache training session to learn how your team can achieve similar results. - -Building Gradle projects doesn't stop with the developer's machine. [Continuous Integration](https://en.wikipedia.org/wiki/Continuous_integration) (CI) has been a long-established practice for running a build for every single change committed to version control to tighten the feedback loop. - -In this guide, we'll discuss how to configure [Travis CI](https://travis-ci.org/) for a typical Gradle project. - -## What you'll need - -* A text editor -* A command prompt -* The Java Development Kit (JDK), version 1.8 or higher - -## Setup a typical project - -As example, this guide is going to focus on a Java-based project. More specifically, a Gradle plugin written in Java and tested with [Spek](https://www.spekframework.org/). First, we'll get the project set up on your local machine before covering the same steps on CI. - -Just follow these steps: - -### Clone the [Gradle Site Plugin](https://github.com/gradle/gradle-site-plugin) repository - -```shell -$ git clone https://github.com/gradle/gradle-site-plugin.git -Cloning into 'gradle-site-plugin'... -$ cd gradle-site-plugin -``` - -### Build the project - -As a developer of a Java project, you'll typically want to compile the source code, run the tests and assemble the JAR artifact. That's no different for Gradle plugins. The following command achieves exactly that: - -```shell -$ ./gradlew build - -BUILD SUCCESSFUL -14 actionable tasks: 14 executed -``` - -The project provides the [Gradle Wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html) as part of the repository. It is a recommended practice for any Gradle project as it enables your project to be built on CI without having to install the Gradle runtime. - -### Build scan integration - -The sample project is equipped with support for generating [build scans](https://scans.gradle.com/). Running the build with the command line option `--scan` renders a link in the console. - -```shell -$ ./gradlew build --scan -Publishing build scan... -https://gradle.com/s/7mtynxxmesdio -``` - -The following section will describe how to build the project with the help of Travis CI. - -## Configure Travis CI - -Travis CI is a free, cloud-based CI solution provider making it an excellent choice for open source projects. You can build any project as long as it is hosted on GitHub as a public repository. Travis CI does not provide built-in options to post-process produced artifacts of the build (e.g., host the JAR file or the HTML test reports). You will have to use external services (like S3) to [transfer the files](https://docs.travis-ci.com/user/uploading-artifacts/). - -### Create the configuration file - -Travis CI requires you to check in a [configuration file](https://docs.travis-ci.com/user/customizing-the-build/) with your source code named `.travis.yml`. This file contains all relevant instructions for building the project. - -The following configuration file tells Travis CI to build a Java project with JDK 8, skip the usual [default execution step](https://docs.travis-ci.com/user/job-lifecycle/#skip-the-installation-phase), and run the Gradle build with the Wrapper. - -```yaml -language: java -install: skip - -os: linux -dist: trusty -jdk: oraclejdk8 - -script: - - ./gradlew build --scan -s -``` - -Select the project from the Travis CI profile. After activating the repository from the dashboard, the project is ready to be built with every single commit. - -![Enabling a project](images/travis-enable-project.png) - -**NOTE:** Configuring [build scans](https://scans.gradle.com/) is especially helpful on cloud CI systems like Travis CI because it has additional environment and test results information that are difficult to obtain otherwise. - -### Enable caching of downloaded artifacts - -Gradle's dependency management mechanism resolves declared modules and their corresponding artifacts from a binary repository. Once downloaded, the files will be re-used from the cache. You need to tell Travis CI explicitly that you want to [store and use the Gradle cache and Wrapper](https://docs.travis-ci.com/user/languages/java/#caching) for successive invocations of the build. - -```yaml -before_cache: - - rm -f $HOME/.gradle/caches/modules-2/modules-2.lock - - rm -fr $HOME/.gradle/caches/*/plugin-resolution/ - -cache: - directories: - - $HOME/.gradle/caches/ - - $HOME/.gradle/wrapper/ -``` - -### Further reading - -You can learn more about advanced Travis CI usage through these resources: - -* [Encrypting sensitive data](https://docs.travis-ci.com/user/encryption-keys/) -* [Modelling a pipeline with build stages](https://docs.travis-ci.com/user/build-stages/) - -## Summary - -Executing Gradle builds on CI can be set up and configured with just a handful of steps. The benefit of receiving fast feedback clearly speaks for itself. If you are not using Travis CI, no problem, many CI products tightly integrate with Gradle as a first-class citizen. \ No newline at end of file diff --git a/docs/cookie-test.md b/docs/cookie-test.md deleted file mode 100644 index db75731..0000000 --- a/docs/cookie-test.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Gradle Cookbook - Cookie Test -template: main.html ---- - -Hello, world! -And congrats, you found a special page where we test cookies! diff --git a/docs/index.md b/docs/index.md index 5298b82..baafbd4 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,6 +1,9 @@ --- -title: Gradle Cookbook -template: home.html +title: Site Shutdown --- -Hello, world! + + +# This Site Has Been Shut Down + +If you are not redirected automatically, please visit [https://community.gradle.org](https://community.gradle.org) \ No newline at end of file diff --git a/docs/integrations/README.md b/docs/integrations/README.md deleted file mode 100644 index be29380..0000000 --- a/docs/integrations/README.md +++ /dev/null @@ -1,10 +0,0 @@ -# Gradle for Java and JVM projects - -This section aggregates tips & tricks for Java and for all -common JVM ecosystem integrations. -Technology specific items can be found elsewhere. - -## Sections - -- [Maven Central publishing](./maven-central/publishing.md) -- [CI systems](../ci/README.md) diff --git a/docs/integrations/maven-central/publishing.md b/docs/integrations/maven-central/publishing.md deleted file mode 100644 index bded814..0000000 --- a/docs/integrations/maven-central/publishing.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: "Publishing to Maven Central" -description: > - Maven Central”, is one of the most popular repositories for publishing artifacts in open source projects. - You can publish your Gradle projects, too. ---- - -# Publishing to Maven Central - -!!! warning "Breaking changes" - - As [announced](https://central.sonatype.org/news/20250326_ossrh_sunset/) by Sonatype, the Sonatype OSS Repository Hosting service (OSSRH) has reached end-of-life on June 30th, 2025. - If you publish your projects to Maven Central, it might be required to reconfigure publishing in your builds, - or update to publishing plugins to newer versions. - See the details below. - -The [Maven Central Repository](https://central.sonatype.com/) service by Sonatype, known in the community as “Maven Central”, is one of the most popular repositories for publishing open source libraries and other distributable artifacts in the Java and Kotlin ecosystems. - -Many developers who use Gradle publish their open source projects to Maven Central. The publishing flow for Maven Central differs significantly from publishing to a generic Maven repository using the [Maven Publish Plugin](https://docs.gradle.org/current/userguide/publishing_maven.html). It involves additional requirements for the artifacts themselves (such as metadata files and signed JARs), as well as for the publishing process (including a staging workflow and server-side verification). Hence, this solution page provides some tips and references. - -## Quick Start - -There are multiple ways to publish to Maven Central, which are described below on this page. -If you are just starting, check out the video below that showcases the -[vanniktech/gradle-maven-publish-plugin](https://github.com/vanniktech/gradle-maven-publish-plugin): - -
- -
- -## Breaking Changes to Maven Central Publishing (June 2025) - -As [announced](https://central.sonatype.org/news/20250326_ossrh_sunset/) by Sonatype, the Sonatype OSS Repository Hosting service (OSSRH) has reached end-of-life on June 30th, 2025\. -OSSRH is an old and deprecated component of the [Maven Central Repository](https://central.sonatype.com/) service used to publish artifacts to Maven Central. - -With the sunset of OSSRH, Maven Central is transitioning to a new hosting implementation, which includes a complete redesign of its APIs. As a result, builds publishing to Maven Central will need to make changes. - -There are two options: - -1. Switch to the new [Central Portal](https://central.sonatype.org/publish/publish-portal-guide/) by - using a dedicated community plugin (recommended). -2. Update to use an [OSSRH compatibility layer](https://central.sonatype.org/publish/publish-portal-ossrh-staging-api/). - -## Plugins for publishing to Maven Central - -As of now, there is no officially recommended plugin for publishing to Maven Central. However, a variety of community-supported plugins and tools are [available](https://plugins.gradle.org/search?term=Maven+Central) on the Gradle Plugin Portal. -Below are some of the most popular options plugins, ranked by GitHub stars, -supporting the new Maven Central Portal API and having more than 10 stars: - -* [vanniktech/gradle-maven-publish-plugin](https://github.com/vanniktech/gradle-maven-publish-plugin) -* [JReleaser](https://jreleaser.org/) -* [GradleUp/nmcp](https://github.com/GradleUp/nmcp) - - -Note that not all listed plugins are actively maintained, and one has to choose carefully based on their use cases. See the recommendations below. - -### Other Plugins - -There are more plugins that are can be used with the _Portal OSSRH Staging API_, -and might be compatible with the new implementation. -Some of the examples having more than 10 stars on GitHub: - -* [deepmedia/MavenDeployer](https://github.com/deepmedia/MavenDeployer) -* [DanySK/maven-central-gradle-plugin](https://plugins.gradle.org/plugin/org.danilopianini.maven-central-gradle-plugin) -* [yananhub/flying-gradle-plugin](https://github.com/yananhub/flying-gradle-plugin) - -## Choosing a plugin for Maven Central publishing - -Choosing the right plugin might be non-trivial, as they have different feature sets and might include different developer experiences in your particular publishing use case. For common Java and Kotlin projects that do not include custom artifacts and distributions, the following selection algorithm can be considered: - -1. If you want to automate the whole release process (packaging, signing, changelog generation, etc.) in a single call and are ready to follow conventions, consider using [JReleaser](https://jreleaser.org/) or another similar tool that automates the whole Pipeline. -2. If you want only a publishing step that follows Maven Central conventions, use [vanniktech/gradle-maven-publish-plugin](https://github.com/vanniktech/gradle-maven-publish-plugin) in the default configuration. - It can publish your Java, Android, and Kotlin libraries, including sources and documentation, to Maven Central or any other Nexus instance. - * See [this video](https://www.youtube.com/watch?v=nd2ULXyBaV8) for the examples -3. If you want to customize the whole publishing flow, e.g., for staging or custom artifact types, use [GradleUp/nmcp](https://github.com/GradleUp/nmcp) or [com.vanniktech.maven.publish.base](https://vanniktech.github.io/gradle-maven-publish-plugin/base/). - -\> DISCLAIMER: This algorithm does not represent an official endorsement by Gradle, Inc. Your mileage may vary, and there are other plugins out there. - -## References - -* [Deploying to OSSRH / Maven Central with Gradle](https://central.sonatype.org/publish/publish-gradle/) \- official documentation page on the Maven Central Documentation site -* [GSoC 2025 \- Maven Central publishing for Gradle with new APIs](https://community.gradle.org/events/gsoc/2025/maven-central-publishing-with-new-api/) \- Google Summer of Code 2025 project targeting the problem area - -## Discuss - -To support this effort, we have created a new **\#maven-central** channel on the [Gradle Community Slack](https://slack.gradle.org/). diff --git a/docs/kotlin/README.md b/docs/kotlin/README.md deleted file mode 100644 index b18a0e2..0000000 --- a/docs/kotlin/README.md +++ /dev/null @@ -1,20 +0,0 @@ -# Gradle for Kotlin - -Gradle is one of the most popular build tools in the Kotlin space, -including classic applications, Kotlin Multiplatform, and [Android](../android/README.md). - -## Official Documentation - -The official documentation for Kotlin development with Gradle -is provided by the Kotlin Foundation on its site. -You can find this documentation [here](https://kotlinlang.org/docs/gradle.html). - -## Featured Recipes - -!!! info - - Work in progress, recipe contributions are [welcome](../CONTRIBUTING.md)! - -## References - -- [Gradle & Kotlin Documentation by the Kotlin Foundation](https://kotlinlang.org/docs/gradle.html) diff --git a/docs/plugin-development/README.md b/docs/plugin-development/README.md deleted file mode 100644 index afdc469..0000000 --- a/docs/plugin-development/README.md +++ /dev/null @@ -1,8 +0,0 @@ -# Gradle for Plugin Development - -## Recipes - -- [Writing Gradle plugins in Kotlin](./kotlin-plugins.md) -- [Ensuring Configuration Cache compatibility](./configuration-cache/README.md) -- [Gradle Reporting API](./reporting-api/README.md) - diff --git a/docs/plugin-development/configuration-cache/README.md b/docs/plugin-development/configuration-cache/README.md deleted file mode 100644 index 6923e9b..0000000 --- a/docs/plugin-development/configuration-cache/README.md +++ /dev/null @@ -1,52 +0,0 @@ -# Ensuring Configuration Cache compatibility - -The configuration and execution phase of builds always take the longest. -You may already know about the build cache, which saves execution time by reusing outputs from past builds. -Gradle's [Configuration Cache](https://docs.gradle.org/current/userguide/configuration_cache.html), -introduced in 6.6 and becoming a preferred mode of execution in Gradle 10, -reuses configuration results from past builds to speed up the configuration phase. - -If you keep an eye on [Gradle public roadmap updates](https://roadmap.gradle.org), -you've probably noticed lots of improvements in Configuration Cache, and steady adoption in the ecosystem. -Still, there is a lot of work to be done in the plugins. -Many Gradle plugins still need to have configuration cache compatibility, and also updates might be needed in end user builds and convention plugins. -For the community plugins for Gradle, -we track the status on [this GitHub Issue](https://github.com/gradle/gradle/issues/13490), and any contributions are more than welcome! - -On this page, we focus on tips for plugins developers and contributors who want to fix Configuration Cache (CC) compatibility in their projects. - -## Main Documentation - -For Configuration Cache adoption and troubleshooting steps, you can already find information -in the main documentation: - -- [Troubleshooting Configuration Cache compatibility](https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:troubleshooting) -- [Configuration Cache Adoption Steps](https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:adoption) -- [Auto-testing configuration Cache compatibility](https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:testing) - - -## Examples and Case Studies - -- [Enabling Gradle Configuration Cache Support in the Liquibase Plugin](./example-config-cache-liquibase-plugin.md) - -## FAQ - -### How to fix "invocation of 'Task.project' at execution time is unsupported"? - -In essence, you should use an alternative service that provides similar functionality. See "Using the Project object" in the [Configuration Cache documentation](https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution). See a sample [fix](https://github.com/gradle/gradle/pull/21555/files#r948986470). - -Also, the configuration cache serialization logic handles `Provider` specially and correctly serializes their values; use `Property` and the providers returned from `org.gradle.api.provider.ProviderFactory` to store values captured from the project or the properties. - -### How to fix "cannot serialize Gradle script object references"? - -This problem most commonly signals that a member of the enclosing script scope, for instance, a member of the `Project` object in the case of project scripts, is being used by a task action: - -```kotlin -tasks.register("printProjectVersion") { - doLast { - println(version) // <---- Project.version captured by a task action - } -} -``` - -A common example is when the `configurations` property or a configuration object (like `runtimeClasspath`) is used by a doLast/doFirst action. Avoid accessing such objects during execution. See a [fix](https://github.com/gradle/gradle/pull/21555/files#r948983984). diff --git a/docs/plugin-development/configuration-cache/example-config-cache-liquibase-plugin.md b/docs/plugin-development/configuration-cache/example-config-cache-liquibase-plugin.md deleted file mode 100644 index c5a8a36..0000000 --- a/docs/plugin-development/configuration-cache/example-config-cache-liquibase-plugin.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -title: Case Study - Enabling Gradle Configuration Cache Support in the Liquibase Plugin -description: > - This page outlines the changes made to the Liquibase Gradle plugin to add support for Gradle's Configuration Cache. ---- - -## 1. Summary - -This page outlines the changes made to the Liquibase Gradle plugin to add support for Gradle's **Configuration Cache**. The primary goal was to improve build performance by making the plugin's tasks compatible with this powerful Gradle feature. - -The core of the work involved refactoring the `LiquibaseTask` and its helper classes to **decouple the task execution logic from the Gradle `Project` model**. This ensures that the task's configuration can be cached and reused across builds, leading to significantly faster development cycles. - ---- - -## 2. The Problem: Configuration Cache Incompatibility - -Gradle's Configuration Cache is a feature that dramatically speeds up builds by serializing the task graph and reusing it for subsequent builds. This allows Gradle to skip the expensive "configuration" phase entirely. - -For the cache to work, a critical rule must be followed: **tasks must not access the `Project` object or related services during their execution phase**. The `Project` model is not serializable and is only available during configuration. - -The previous implementation of the plugin violated this rule in several ways: - -* **Direct Project Access in `LiquibaseTask`:** The main task action (`@TaskAction`) directly accessed the project's `liquibase` extension to get its configuration at execution time. - - ```groovy - // Violation inside LiquibaseTask's execution logic: - def activities = project.liquibase.activities - def runList = project.liquibase.runList - jvmArgs(project.liquibase.jvmArgs) - ``` - -* **Project Dependency in `ArgumentBuilder`:** The `ArgumentBuilder` class, used during task execution, held a reference to the `project` and used it to access project properties, the logger, and the build directory. - - ```groovy - // Violations inside ArgumentBuilder: - project.properties.findAll { ... } - commandArguments += "--output-directory=${project.buildDir}/database/docs" - ``` - -* **Runtime Configuration Resolution:** The task resolved its `liquibaseRuntime` classpath inside its execution logic instead of during the configuration phase. - - ```groovy - // Violation inside LiquibaseTask's execution logic: - def classpath = project.configurations.getByName(LiquibasePlugin.LIQUIBASE_RUNTIME_CONFIGURATION) - ``` - -These violations made the plugin incompatible with the configuration cache, forcing Gradle to reconfigure the project on every single run and preventing users from benefiting from the potential performance gains. - ---- - -## 3. The Solution: Decoupling Execution from Configuration - -The solution was to refactor the plugin to adopt a pattern where all necessary information is gathered from the `Project` during the **configuration phase** and passed into the task as **serializable inputs**. The task's execution logic then operates only on these inputs, with no knowledge of the `Project` object. - -### Step 1: Introduce Serializable Data Transfer Objects (DTOs) - -Two new classes were created to act as simple, serializable data containers: - -1. **`LiquibaseInfo`**: This class is responsible for carrying project-level information that the `ArgumentBuilder` needs. -* *See the new class file: [`LiquibaseInfo.groovy`]([lhttps://github.com/Nouran-11/liquibase-gradle-plugin/blob/fix-cc/src/main/groovy/org/liquibase/gradle/LiquibaseInfo.groovy$0])* - - ```groovy - // org/liquibase/gradle/LiquibaseInfo.groovy - class LiquibaseInfo { - Logger logger - File buildDir - Map liquibaseProperties - - static LiquibaseInfo fromProject(Project project) { - // ... logic to extract properties from the project ... - return new LiquibaseInfo(project.logger, project.buildDir, liquibaseProperties) - } - } - ``` -1. **`ProjectInfo`**: This class holds configuration from the `liquibase { ... }` extension block. -* *See the new class file: [`ProjectInfo.groovy`]([https://github.com/Nouran-11/liquibase-gradle-plugin/blob/fix-cc/src/main/groovy/org/liquibase/gradle/ProjectInfo.groovy$0])* - ```groovy - // org/liquibase/gradle/ProjectInfo.groovy - class ProjectInfo { - List activities - String runList - List jvmArgs - - static ProjectInfo fromProject(Project project) { - // ... logic to extract data from project.liquibase extension ... - return new ProjectInfo(activities, runList, jvmArgs) - } - } - ``` - -The key feature of these classes is the static `fromProject()` factory method. This method acts as the bridge, safely extracting data at configuration time. - -### Step 2: Refactor `ArgumentBuilder` to be Stateless - -The `ArgumentBuilder` was refactored to remove its dependency on the `Project` object. Instead of holding a reference to the project, its methods now require a `LiquibaseInfo` object to be passed in. -* *See the full class changes: **[`ArgumentBuilder.groovy`]([https://github.com/liquibase/liquibase-gradle-plugin/blob/master/src/main/groovy/org/liquibase/gradle/ArgumentBuilder.groovy$0])** -> **[`ArgumentBuilder.groovy`]([https://github.com/Nouran-11/liquibase-gradle-plugin/blob/fix-cc/src/main/groovy/org/liquibase/gradle/ArgumentBuilder.groovy$0])*** -**Before:** - -```groovy -// ArgumentBuilder.groovy -def buildLiquibaseArgs(Activity activity, commandName, supportedCommandArguments) { - // ... code that used internal `project` reference ... -} -``` - -**After:** - -```groovy -// ArgumentBuilder.groovy -def buildLiquibaseArgs(Activity activity, commandName, supportedCommandArguments, LiquibaseInfo liquibaseInfo) { - // ... code now uses liquibaseInfo.logger, liquibaseInfo.buildDir, etc. ... -} -``` - -## Step 3: Update LiquibaseTask to Use Inputs - -The `@TaskAction` method (`exec` and its helpers) was rewritten to read from configured input properties instead of the project. This table highlights the specific transformations that eliminate configuration cache violations at execution time: -* *See the full class changes: **[`LiquibaseTask.groovy`]([https://github.com/liquibase/liquibase-gradle-plugin/blob/master/src/main/groovy/org/liquibase/gradle/LiquibaseTask.groovy$0])** -> **[`LiquibaseTask.groovy`]([https://github.com/Nouran-11/liquibase-gradle-plugin/blob/fix-cc/src/main/groovy/org/liquibase/gradle/LiquibaseTask.groovy$0])*** - -| Violation Type | Before | After | -|---------------------------|-------------------------------------------|---------------------------------------------| -| Accessing Extension Data | `jvmArgs(project.liquibase.jvmArgs)` | `jvmArgs(projectInfo.get().jvmArgs)` | -| Resolving Classpaths | `setClasspath(project.configurations.getByName(...))` | The `classPath` property is assigned in the task's constructor | -| Accessing Project Properties | `argumentBuilder` reads `project.properties` | `argumentBuilder` receives `liquibaseInfo` with properties | -| Accessing buildDir | `argumentBuilder` reads `project.buildDir` | `argumentBuilder` receives `liquibaseInfo` with build dir | ---- - -## 4. Verification: The Configuration Cache Test - -To provide concrete proof of these improvements, a dedicated integration test was added. This test runs a build with the configuration cache enabled, verifying that the plugin's tasks execute successfully and are correctly stored and retrieved from the cache on subsequent runs. This confirms that the refactoring was successful and the plugin is now fully compatible. - -See the test in action: [Configuration Cache Test]([https://github.com/Nouran-11/liquibase-gradle-plugin/blob/master/src/test/groovy/org/liquibase/gradle/ConfigurationCacheSpec.groovy$0]) - ---- - -## 5. Conclusion - -In conclusion, this refactoring effort was centered on achieving full compatibility with Gradle's Configuration Cache. By decoupling task execution from the project model, the plugin now allows Gradle to serialize its state and entirely skip the configuration phase on subsequent runs. This unlocks the core performance promise of the configuration cache, resulting in a dramatically faster and more efficient development workflow. - diff --git a/docs/plugin-development/kotlin-plugins.md b/docs/plugin-development/kotlin-plugins.md deleted file mode 100644 index 53bca31..0000000 --- a/docs/plugin-development/kotlin-plugins.md +++ /dev/null @@ -1,163 +0,0 @@ -# Writing Gradle plugins in Kotlin - -Kotlin has [a great Java interoperability story](https://kotlinlang.org/docs/java-to-kotlin-interop.html), making it a good language to write Gradle plugins. - -For complete compatibility, several aspects require extra care. This page gives an overview of the different compatibility issues and recommended setup to avoid them. - -## Gradle compatibility - -When executing a build, Gradle [forces its own version of `kotlin-stdlib`](https://github.com/gradle/gradle/issues/16345), the embedded version. - -For this reason, your plugin must depend on a version of `kotlin-stdlib` that is compatible with the embedded version. - -Gradle publishes the embedded versions in the [Kotlin compatibility matrix](https://docs.gradle.org/current/userguide/compatibility.html#kotlin). - -For an example, at the time of writing, Gradle 8.10 embeds `kotlin-stdlib:1.9.24`. - -### Making your code compatible with the Kotlin embedded version - -You can use a more recent version of the Kotlin Gradle Plugin, but you'll have to make sure not to call any 2.0 API: - -```kotlin -plugins { - // Use latest version of the Kotlin Gradle Plugin - id("org.jetbrains.kotlin.jvm").version("2.0.21") - // java-gradle-plugin creates marker publications and plugin descriptors - id("java-gradle-plugin") -} - -kotlin { - compilerOption { - // Make sure your plugin code only uses 1.9 APIs - apiVersion.set(KotlinVersion.KOTLIN_1_9) - // Make sure your older Gradle versions can compile build.gradle.kts scripts against your plugin. - languageVersion.set(KotlinVersion.KOTLIN_1_9) - } - // Also make sure to depend on 1.9 kotlin-stdlib - // See also https://youtrack.jetbrains.com/issue/KT-53462 - coreLibrariesVersion = "1.9.24" -} -``` - -### Ensuring dependencies are compatible with the Kotlin embedded version - -In addition to your own code, your dependencies must also use a compatible version of `kotlin-stdlib`. - -Because the compiler doesn't run on dependencies, `apiVersion` does not help here, you'll have to check that the dependencies do not depend on a newer version of `kotlin-stdlib`. - -This can be done using a custom Gradle task: - -```kotlin -/** - * An example of a task that checks that no kotlin-stdlib > 1.9.24 is pulled - * in the classpath. - * Configuration cache and edge cases are left as an exercise to the reader. - */ -tasks.register("checkGradleCompatibility") { - doLast { - val root = configurations.getByName("runtimeClasspath").incoming.resolutionResult.rootComponent.get() - root.dependencies.forEach { - if (it is ResolvedDependencyResult) { - val rdr = it - val requested = rdr.requested - val selected = rdr.selected - if ( - requested is ModuleComponentSelector - && requested.group == "org.jetbrains.kotlin" - && requested.module == "kotlin-stdlib" - ) { - - val requestedVersion = requested.version - val selectedVersion = selected.moduleVersion?.version - check (selectedVersion == requestedVersion) { - "kotlin-stdlib was upgraded to $selectedVersion" - } - } - } - } - } -} -``` - -### Alternative #1: relocating kotlin-stdlib - -If the steps above are too complicated, maybe because a required dependency uses a newer version of Kotlin, or because your own plugin code requires newer Kotlin features, you can shadow a relocated version of `kotlin-stdlib` that doesn't clash with the Gradle embedded one. - -To do this, you can use [R8](https://github.com/GradleUp/GR8). You can read more about the process [in this dedicated blog post](https://blog.mbonnin.net/use-latest-kotlin-in-your-gradle-plugins). - -!!! note - [Shadow](https://github.com/GradleUp/shadow/) could be an alternative, but we have found that it doesn't work reliably because [it relocates String constants as well](https://github.com/GradleUp/shadow/issues/232) - -### Alternative #2: using separate classloaders - -Another solution if you want to use a newer `kotlin-stdlib` without using relocation is to run your code in a separate, isolated, classloader. The glue code of your plugin and initialization still has to be compatible but as soon as you switch to a new classloader, you can use any dependencies without any risk of incompatibilities. - -Projects such as [Gratatouille](https://github.com/GradleUp/Gratatouille) can help with that. - -## Groovy interoperability - -Because your plugin may be used from Groovy build scripts (`build.gradle`), it is important to have Groovy compatibility in mind. - -### General interoperability - -In general Groovy does not know anything about Kotlin. Avoid Kotlin-only features such as: - -- extension functions -- default parameter values -- function types -- receivers -- etc... - -These features may be used in extra functionality for Kotlin callers, but it is important that all the base functionality of your plugin does not require them. - -### Closures - -Closure are an important piece of the Groovy build scripts. Every block is a closure under the hood. - -Because dealing with Groovy closure from Kotlin (and Java) is cumbersome, Gradle allows to use `Action` instead. For all types instantiated by Gradle (tasks, extensions, [newInstance()](https://docs.gradle.org/current/kotlin-dsl/gradle/org.gradle.api.model/-object-factory/new-instance.html), etc..), the Gradle runtime decorates all functions with a single `Action` parameter with an matching function accepting a closure ([doc](https://docs.gradle.org/current/userguide/kotlin_dsl.html#groovy_closures_from_kotlin)). - -For an example, the Kotlin code below: - -```kotlin -open class MyExtension { - fun doStuff(action: Action) { - // ... - } -} -``` - -can be called from groovy with a closure: - -```groovy -myExtension { - doStuff { - // This is a closure even though groovy doesn't know about Action - // ... - } -} -``` - -## Difference with `build.gradle.kts` scripts - -If you are used to writing `build.gradle.kts` files, you may use the `kotlin-dsl` Gradle plugin to write your plugins. - -`kotlin-dsl` configures the Kotlin compiler so that you can use precompiled scripts plugins and/or write similar syntax in your regular `.kt` files. - -The `kotlin-dsl` plugin: - -* applies `"java-gradle-plugin"`. -* applies `kotlin-embedded` to use the same Kotlin embedded version as your Gradle distribution. -* applies the `"kotlin-dsl-precompiled-script-plugins"` allowing to use `build.gradle.kts` files. -* adds `gradleKotlinDsl()` to the `compileOnly` configuration. -* configures the `sam-with-receiver` Kotlin compiler plugin to transform `it.` usages into `this.`. -* configures the `kotlin-assignment` Kotlin compiler plugin to allow setting `Property` with the `=` operator. -* sets Kotlin `apiVersion` and `languageVersion` according to Gradle [compatibility matrix](https://docs.gradle.org/current/userguide/compatibility.html#kotlin). -* adds the `-Xsam-conversions=class` compiler option. -* adds others compiler options for compatibility: - * `-java-parameters` to support [Java 8 Parameter](https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Parameter.html) class and getting method parameters through reflection - * `-Xjvm-default=all` to add link: [Default methods in interfaces](https://kotlinlang.org/docs/java-to-kotlin-interop.html#default-methods-in-interfaces) - * `-Xjsr305=strict` for [increased null safety](https://kotlinlang.org/docs/java-interop.html#compiler-configuration) - -This is a significant departure from the baseline Kotlin configuration so be aware of the trade-offs when using `kotlin-dsl`. - -Also, `kotlin-dsl` targets the Kotlin embedded version of your current distribution. If you want to be compatible with lower versions of Gradle, using the `com.jetbrains.kotlin.jvm` plugin provides more flexibility. diff --git a/docs/plugin-development/reporting-api/README.md b/docs/plugin-development/reporting-api/README.md deleted file mode 100644 index 2debd46..0000000 --- a/docs/plugin-development/reporting-api/README.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -title: Gradle Reporting API -description: > - Gradle has a reporting system that tasks creating reports can expose, - letting users configure formats and output locations. ---- - -Gradle has a reporting system that tasks creating reports can expose, letting users configure formats and output locations. -For plugin developers that would like closer integration with Gradle systems, to integrate the [Reporting API](https://docs.gradle.org/current/javadoc/org/gradle/api/reporting/Reporting.html) -into your own Gradle plugin, two things are needed: -a [ReportContainer](https://docs.gradle.org/current/javadoc/org/gradle/api/reporting/ReportContainer.html) class and -a [Report](https://docs.gradle.org/current/javadoc/org/gradle/api/reporting/Report.html) -object. - -We’ll be working with the [VerifyPluginProjectConfigurationTask](https://github.com/JetBrains/intellij-platform-gradle-plugin/blob/476130fa41347ef4e5480fb44b9d454e51aa7a18/src/main/kotlin/org/jetbrains/intellij/platform/gradle/tasks/VerifyPluginProjectConfigurationTask.kt#L44), a task from the [IntelliJ Platform Gradle Plugin](https://github.com/JetBrains/intellij-platform-gradle-plugin/tree/476130fa41347ef4e5480fb44b9d454e51aa7a18) -that does the simple job of validating a plugin project’s configuration. - -!!! note - Tested with Gradle 9.0.0 - -## Declaring Reporting Support in a Task - -Tasks that produce reports must implement the `Reporting` interface with a type argument that extends `ReportContainer`: - -```kotlin -abstract class VerifyPluginProjectConfigurationTask : DefaultTask(), Reporting { - // skipped lines -} -``` - -## Defining the `ReportContainer` Contract - -`VerifyPluginConfigurationReports` is an interface that extends `ReportContainer`. `SingleFileReport` -is a useful wrapper around `Report` that represents that our output will be a single file. If your report was a group of files -you’d want to put in a directory, of which a `DirectoryReport` would be used instead. - -```kotlin -interface VerifyPluginConfigurationReports: ReportContainer { - @get:Nested - val txt: SingleFileReport -} -``` - -This interface defines the public contract of reports available to users. Having multiple report formats, for example, text, -html and/or markdown, can be defined like so: - -```kotlin -interface VerifyPluginConfigurationReports: ReportContainer { - @get:Nested - val txt: SingleFileReport - - @get:Nested - val html: SingleFileReport - - @get:Nested - val markdown: SingleFileReport -} -``` - -If you need a custom report with additional properties beyond say `SingleFileReport`, you can define your own report type -(e.g., an interface extending `SingleFileReport`) and still provide it from your `ReportContainer`. - -Next, we need an implementation which will define how exactly our reports will be created: - -```kotlin -class VerifyPluginConfigurationReportsImpl : VerifyPluginConfigurationReports { - -} -``` - -## Implementing the `ReportContainer` - -Providing an implementation of our report container requires that we override over 40 different methods. -To avoid doing this, we can delegate access to these methods to another `ReportContainer` class with the help of `DelegatingReportContainer`. - -Since `DelegatingReportContainer`, `DefaultReportContainer` and `DefaultSingleFileReport` are internal classes, -keep their usages inside your implementation so your plugin’s API only exposes public Gradle types like `ReportContainer` and `SingleFileReport`. - -```kotlin -class VerifyPluginConfigurationReportsImpl @Inject constructor( - owner: Describable, - objectFactory: ObjectFactory, -) : DelegatingReportContainer( - DefaultReportContainer.create(objectFactory,SingleFileReport::class.java) { factory -> - listOf(factory.instantiateReport(DefaultSingleFileReport::class.java, "txt", owner)) - } - ), - VerifyPluginConfigurationReports { - -} -``` - -`DefaultSingleFileReport` requires a name and a `Describable` object. -And the `DefaultReportContainer` contains a `create` function that allows us to create a new report container by -supplying an `ObjectFactory` instance, the type of reports that this container holds and a generator that creates those reports using `ReportGenerator`: - -```kotlin -public interface ReportGenerator { - Collection generateReports(ReportFactory factory); -} -``` - -Here, `generateReports` demands that we return a collection of our report types, so using the `ReportFactory` we can instantiate our report by -passing in the required constructor arguments: name of the report and a `Describable` object. - -Next, we must provide an implementation for our `txt` property by referencing the name of our report: - -```kotlin -class VerifyPluginConfigurationReportsImpl @Inject constructor( - owner: Describable, - objectFactory: ObjectFactory, -) : DelegatingReportContainer( - DefaultReportContainer.create(objectFactory,SingleFileReport::class.java) { factory -> - listOf(factory.instantiateReport(DefaultSingleFileReport::class.java, "txt", owner)) - } -), - VerifyPluginConfigurationReports { - - override val txt: SingleFileReport get() = getByName("txt") - -} -``` - -## Wiring the `ReportContainer` into the Task - -After defining our report container and report objects, back to our task to start working with them: - -```kotlin -abstract class VerifyPluginProjectConfigurationTask : DefaultTask(), Reporting { - // skipped lines - - @get:Inject - abstract val objectFactory: ObjectFactory - - private val verifyPluginProjectReports : VerifyPluginConfigurationReports = objectFactory.newInstance( - VerifyPluginConfigurationReportsImpl::class.java, - Describables.quoted("Task", identityPath) - ) - // skipped lines -} -``` - -We will not be able to create an instance of `VerifyPluginConfigurationReportsImpl` because it’s a `final` class, so let’s make it `open`: - -```kotlin -open class VerifyPluginConfigurationReportsImpl @Inject constructor( - owner: Describable, - objectFactory: ObjectFactory, -) /*skipped lines*/ { - // skipped lines -} -``` - -Override these functions to rely on our reports property `verifyPluginProjectReports`: - -```kotlin -abstract class VerifyPluginProjectConfigurationTask : DefaultTask(), Reporting { - // skipped lines - - @Nested - override fun getReports(): VerifyPluginConfigurationReports = verifyPluginProjectReports - - override fun reports(closure: Closure<*>): VerifyPluginConfigurationReports { - return reports(ClosureBackedAction(closure)) - } - - override fun reports(configureAction: Action): VerifyPluginConfigurationReports { - configureAction.execute(verifyPluginProjectReports) - return verifyPluginProjectReports - } - // skipped lines -} -``` - -We annotate `getReports()` with `@Nested` so Gradle inspects the returned report container’s properties (like `txt`, `html`, `markdown`) and their annotations. - -## Setting up Report Outputs - -When configuring our task, we can go ahead to use our function to set up our reports: - -```kotlin -reports { - txt.required.set(true) - txt.outputLocation.convention(project.layout.buildDirectory.file("reports/verifyPluginConfiguration/report.txt")) -} -``` - -## Writing Data to Reports - -Finally, writing to our reports can be done in this fashion: - -```kotlin -if (verifyPluginProjectReports.txt.required.get()) { - verifyPluginProjectReports.txt.outputLocation.get().asFile.writeText(it) -} -``` - -## References - -- [PR for VerifyPluginProjectConfigurationTask, GSoC 2025](https://github.com/JetBrains/intellij-platform-gradle-plugin/pull/2016) -- [ReportContainer DSL](https://docs.gradle.org/current/dsl/org.gradle.api.reporting.ReportContainer.html) -- [Reporting DSL](https://docs.gradle.org/current/dsl/org.gradle.api.reporting.Reporting.html) -- [Report DSL](https://docs.gradle.org/current/dsl/org.gradle.api.reporting.Report.html) -- [SingleFileReport DSL](https://docs.gradle.org/current/dsl/org.gradle.api.reporting.SingleFileReport.html) -- [DirectoryReport DSL](https://docs.gradle.org/current/dsl/org.gradle.api.reporting.DirectoryReport.html) -- [https://github.com/gradle/gradle/issues/7063](https://github.com/gradle/gradle/issues/7063) \ No newline at end of file diff --git a/docs/preface.md b/docs/preface.md deleted file mode 100644 index 2c0c2e7..0000000 --- a/docs/preface.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: "The Gradle Cookbook" -description: > - Gradle Cookbook is an open-source collection of recipes, guides and examples for the Gradle Build Tool. ---- - -Gradle Cookbook is an open-source collection of recipes, guides and examples for the Gradle Build Tool. -This is a complementary resource to the official [Gradle User Manual](https://docs.gradle.org/current/userguide/userguide.html), -which covers core capabilities maintained by the Gradle team. - -The goal of this portal is to offer solution-based documentation for end users about external integrations, -including but not limited to -CI/CD tools, IDEs, -support for languages and frameworks, -and various peripheral tools. - -In the Gradle Cookbook, _Gradle Build Tool_ is abbreviated _Gradle_. - -!!! note - The Gradle Cookbook is under active development (see the roadmap item [here](https://github.com/gradle/community/issues/42)). - Its structure, scope and links may change, and we're working on adding more content. - Any contributions are welcome, see the [Contributor Guide](./CONTRIBUTING.md)! - -## Why and How? - -The Gradle Build Tool ecosystem is huge, it includes many plugins, integrations, developer tools and other components. -Not all of them can be covered in the [Gradle User Manual](https://docs.gradle.org/current/userguide/userguide.html) -which represents core documentation maintained for each Gradle release. -Moreover, being tied to the Gradle release contribution process and the release cycle makes it more difficult to contribute there. -Maintaining documentation has been challenging for us as well, -leading to many outdated pages. - -So, we decided to build a second resource as an extension to the Gradle User Manual, -with the following in mind: - -- Gradle Cookbook remains an official resource under `community.gradle.org`. - It is not a second-class citizen, just another structure that is not tied to the Gradle release cycle -- Pages should be focused on offering solutions to end users for particular use cases, - hence the _Cookbook_ -- We follow the Wiki-alike collaboration style, - with a lower barrier to contribute than `gradle/gradle`. - Some sections can get explicit maintainers/reviewers over time. -- We use Documentation-as-Code, with simple Markdown or Asciidoc files used as a source -- Minimizing duplication. - We can include documentation from other sources under the [Gradle GitHub organization](https://github.com/gradle/) - -## Trademark Notice - -Gradle and the Gradlephant logo (the "Gradle Marks") are registered trademarks of Gradle, Inc. and/or its subsidiaries. -Use of the Gradle Marks the Gradle Cookbook pages is for identification purposes only and does not imply sponsorship or endorsement by Gradle, Inc. -In the Gradle Cookbook, "Gradle" typically means "Gradle Build Tool" and does not reference Gradle Inc. and/or its subsidiaries. - -See the [Gradle Branding Guidelines](https://gradle.com/brand/) for more information about -trademark usage and the approval process. - -## References - -- [Gradle User Manual](https://docs.gradle.org/current/userguide/userguide.html) -- [Other Documentation Locations](https://community.gradle.org/contributing/documentation) \ No newline at end of file diff --git a/docs/troubleshooting/README.md b/docs/troubleshooting/README.md deleted file mode 100644 index 2700890..0000000 --- a/docs/troubleshooting/README.md +++ /dev/null @@ -1,11 +0,0 @@ -# Troubleshooting Gradle - -Tools, tips and tricks for troubleshooting issues with Gradle. - -!!! info - - Work in progress, recipe contributions are [welcome](../CONTRIBUTING.md)! - -## References - -- [Official Troubleshooting Guide](https://docs.gradle.org/current/userguide/troubleshooting.html) diff --git a/mkdocs.yml b/mkdocs.yml index 3cffd1d..7f281fb 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,195 +1,25 @@ site_name: Gradle Cookbook site_author: Gradle Contributors -site_description: >- - Gradle Cookbook is an open-source collection of recipes, guides and examples for the Gradle Build Tool. - This is a complementary resource to the official Gradle User Manual. -copyright: > - Copyright © 2025 - All contributors to the repository and included components. - Gradle®, Develocity®, Build Scan®, and the Gradlephant logo are registered trademarks of Gradle, Inc. - On this resource, "Gradle" typically means "Gradle Build Tool" and does not reference Gradle, Inc. and/or its subsidiaries. -docs_dir: docs +site_description: This site has been shut down. Please refer to https://community.gradle.org. +site_url: https://cookbook.gradle.org +copyright: Copyright © 2025 - Gradle® + repo_url: https://github.com/gradle/cookbook repo_name: Gradle Cookbook edit_uri: edit/main/docs/ -site_url: https://cookbook.gradle.org -# Build -site_dir: _site - -nav: - - Overview: - - preface.md - - chapters.md - - Contributing: CONTRIBUTING.md - - Integrations: - - Overview: integrations/README.md - - Maven Central Publishing: integrations/maven-central/publishing.md - - Gradle and CI: - - Summary: ci/README.md - - Jenkins: ci/jenkins.md - - TeamCity: ci/teamcity.md - - GitHub Actions: ci/github-actions.md - - GitLab CI: ci/gitlab-ci.md - - Travis CI: ci/travis-ci.md - - Gradle for Kotlin: kotlin/README.md - - Gradle for Android: android/README.md - - Troubleshooting Gradle: troubleshooting/README.md - - Plugin Development: - - Summary: plugin-development/README.md - - Kotlin plugin development: plugin-development/kotlin-plugins.md - - Ensuring Configuration Cache compatibility: - - Overview: plugin-development/configuration-cache/ - - Case study - Liquibase Plugin: plugin-development/configuration-cache/example-config-cache-liquibase-plugin.md - - Gradle Reporting API: plugin-development/reporting-api/README.md - -# Theme theme: name: material - custom_dir: overrides/ - highlightjs: true - features: - - announce.dismiss - - content.action.edit - - content.action.view - - content.code.annotate - - content.code.copy - - content.code.select - - content.tabs.link - - content.tooltips - # - header.autohide - # - navigation.expand - - navigation.footer - # NOT compatible qith toc.integrate - # - navigation.indexes - - navigation.path - # - navigation.instant - # - navigation.instant.prefetch - # - navigation.instant.progress - # - navigation.prune - - navigation.sections - - navigation.expand - - navigation.tabs - # - navigation.tabs.sticky - - navigation.top - - navigation.tracking - - search.highlight - - search.share - - search.suggest - - toc.follow - - toc.integrate palette: - scheme: default - media: "(prefers-color-scheme: light)" - primary: custom - toggle: - icon: material/brightness-7 - name: Switch to dark mode - - - scheme: slate - media: "(prefers-color-scheme: dark)" primary: custom - toggle: - icon: material/brightness-4 - name: Switch to light mode - font: - # TODO: use the site's scheme - # text: Lato Lite - code: Roboto Mono - favicon: assets/images/logos/gradle.svg - logo: assets/images/logos/gradle.svg - icon: - repo: fontawesome/brands/github - - -extra_css: - - assets/css/gradle.css - -extra: - social: - - icon: fontawesome/brands/slack - link: https://gradle.org/slack-invite - name: Slack - - icon: fontawesome/brands/github - link: https://github.com/gradle - name: GitHub - - icon: fontawesome/brands/x-twitter - link: https://twitter.com/gradle - name: Twitter/X - - icon: fontawesome/brands/linkedin - link: https://www.linkedin.com/company/gradle - name: LinkedIn - - icon: fontawesome/brands/mastodon - link: https://mastodon.social/@Gradle - name: Mastodon - analytics: - provider: custom - - plugins: - search - - autorefs -# FIXME: Collision on GitHub Actions, to be fixed later -# - macros - - mkdocs-pdf - # OpenGraphs - - social: - cards_layout_options: - background_color: "#010002" - font_family: Lato - # - group: - # enabled: !ENV [FULL_BUILD, true] - # plugins: - # - multirepo: - # cleanup: false - # keep_docs_dir: true - # nav_repos: - # - name: github-actions - # import_url: 'https://github.com/gradle/actions?branch=main&edit_uri=/blob/main/' - # imports: [ "README.md", "*" ] - - git-revision-date-localized - - git-committers: - repository: gradle/cookbook - branch: main - - mkdocs-nav-weight: - # Index/README go first in folder includes - index_weight: -10 - - - with-pdf: - enabled_if_env: BUILD_PDF - output_path: pdf/cookbook.pdf - author: Gradle Contributors - # FIXME: Needs rendering style to include the trademark notice & Co into the header - copyright: > - Copyright © 2024 - All contributors to the repository and included components. - cover: true - cover_title: The Gradle Cookbook - cover_subtitle: Open Source Recipes for Gradle Build Tool - cover_logo: https://gradle.com/wp-content/themes/fuel/assets/img/branding/gradle-elephant-icon-gradient.svg - back_cover: true - toc_title: Table of Contents - toc_level: 3 - show_anchors: true - -# Markdown markdown_extensions: - - pymdownx.highlight: - anchor_linenums: true - line_spans: __span - pygments_lang_class: true - - pymdownx.details - - pymdownx.inlinehilite - - pymdownx.snippets - - pymdownx.superfences - - pymdownx.tabbed: - alternate_style: true - toc: permalink: '#' - - admonition - - attr_list - - pymdownx.emoji: - emoji_index: !!python/name:material.extensions.emoji.twemoji - emoji_generator: !!python/name:material.extensions.emoji.to_svg - - pymdownx.tasklist: - custom_checkbox: true + +nav: + - Home: index.md \ No newline at end of file diff --git a/overrides/home.html b/overrides/home.html deleted file mode 100644 index 2078ae5..0000000 --- a/overrides/home.html +++ /dev/null @@ -1,113 +0,0 @@ -{% extends "main.html" %} -{% block tabs %} - {{ super() }} - - - - -
-
-
-
- Gradle Logo -
-
-

Gradle Cookbook

-

{{ config.site_description }} Contributions are welcome!

-
-
- - Overview - - - Chapters - -
-
-
-
-{% endblock %} - -{% block content %}{% endblock %} - -{% block footer %} - {{ super() }} -{% endblock %} diff --git a/overrides/main.html b/overrides/main.html deleted file mode 100644 index 275bfd6..0000000 --- a/overrides/main.html +++ /dev/null @@ -1,15 +0,0 @@ -{% extends "base.html" %} - -{% block announce %} -{% endblock %} - -{% block scripts %} - {{ super() }} -{% endblock %} - -{% block footer %} - - - - {{ super() }} -{% endblock %} diff --git a/overrides/partials/integrations/analytics/custom.html b/overrides/partials/integrations/analytics/custom.html deleted file mode 100644 index 3b4fe26..0000000 --- a/overrides/partials/integrations/analytics/custom.html +++ /dev/null @@ -1,7 +0,0 @@ - - - -