bancolombia · juancgalvis · Aug 6, 2025 · Aug 4, 2025 · Aug 4, 2025 · Aug 4, 2025
diff --git a/.github/workflows/gradle.yml b/.github/workflows/gradle.yml
@@ -57,19 +57,19 @@ jobs:
       - name: Set up JDK 21
         uses: actions/setup-java@c5195efecf7bdfc987ee8bae7a71cb8b11521c00 # v4.7.1
         with:
-          distribution: 'temurin' 
+          distribution: 'temurin'
           java-version: 21
       - name: Validate code formatting
         run: ./gradlew verGJF
       - name: Execute build test and report
         run: ./gradlew jacocoTestReport --refresh-dependencies --no-daemon --continue
-      - name: copy the reportTest to codeCoverage
+      - name: Copy the reportTest to codeCoverage
         run: cp build/reports/jacoco/report.xml jacoco.xml || echo "Code coverage failed"
       - name: Push codeCoverage to Codecov
         run: bash <(curl -s https://codecov.io/bash)
       - name: Run sonar
         if: github.event.pull_request.head.repo.fork == false && !startsWith(github.event.pull_request.head.ref, 'dependabot/')
-        run: ./gradlew sonar --stacktrace 
+        run: ./gradlew sonar --stacktrace
           -Dsonar.token=${{ secrets.SONAR_TOKEN }}
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
@@ -87,6 +87,11 @@ jobs:
       - name: Publish local
         if: steps.changes.outputs.templates == 'true'
         run: ./sh_publish_plugin_local.sh
+      # Set up Gradle
+      - name: Set up Gradle
+        uses: gradle/actions/setup-gradle@d9c87d481d55275bb5441eef3fe0e46805f9ef70 # v3.5.0
+        with:
+          gradle-version: 8.8
       # Generated code reactive
       - name: Generate reactive project to scan
         if: steps.changes.outputs.templates == 'true'

diff --git a/docs/docs/1-intro.md b/docs/docs/1-intro.md
@@ -129,14 +129,14 @@ To explicitly enable analytics and avoid the notification message
 
 ```shell
 gradle analytics --enabled true
-# o gradle a --enabled true
+# gradle a --enabled true
 ```
 
 To disable analytics
 
 ```shell
 gradle analytics --enabled false
-# # o gradle a --enabled false
+# gradle a --enabled false
 ```
 
 ### What is collected?
@@ -159,7 +159,7 @@ Usage analytics may include the following information:
 # Whats Next?
 
 Read
-more  [About Clean Architecture](https://medium.com/bancolombia-tech/clean-architecture-aislando-los-detalles-4f9530f35d7a)
+more [About Clean Architecture](https://medium.com/bancolombia-tech/clean-architecture-aislando-los-detalles-4f9530f35d7a)
 
 We also have an [Elixir](https://bancolombia.github.io/scaffold-clean-architecture-ex/) variant
 

diff --git a/docs/docs/2-getting-started.md b/docs/docs/2-getting-started.md
@@ -11,6 +11,11 @@ sidebar_position: 2
 - To use the [plugin](https://plugins.gradle.org/plugin/co.com.bancolombia.cleanArchitecture) you need Gradle version
   8.8 or later.
 
+:::note[Recommended Gradle Version]
+For optimal performance and to enable all **[Gradle cache properties](advanced/gradle-cache)**, it is recommended to use
+Gradle [8.14.3 or higher](https://gradle.org/releases/).
+:::
+
 ## Using the plugin
 
 To start you need to create a directory for the project, then you should add a `build.gradle` file with following

diff --git a/docs/docs/5-contributing.md → docs/docs/3-contributing.md b/docs/docs/5-contributing.md → docs/docs/3-contributing.md
@@ -35,34 +35,41 @@ make sure this local email is also added to your
 [GitHub email list](https://github.com/settings/emails).
 
 ### Step 2: Hook
-We have a pre-commit hook to format the code and warrant the unit test pass, you only need to install this with the following command.
 
-```text
-$ ./gradlew installGitHooks
+We have a pre-commit hook to format the code and warrant the unit test pass, you only need to install this with the
+following command.
+
+```bash
+./gradlew installGitHooks
 ```
+
 if you will be interest to format the code in any time , execute this command
 
-```text
-$ ./gradlew goJF
+```bash
+./gradlew goJF
 ```
+
 ### Step 3: Branch
 
 As a best practice to keep your development environment as organized as
 possible, create local branches to work within. These should also be created
 directly off of the `master` branch.
 
-```text
-$ git checkout -b my-branch -t upstream/master
+```bash
+git checkout -b my-branch -t upstream/master
 ```
 
-We suggest that the name of the branch be separated with hyphens and be concise with what you want to solve, it does not have to start with the word feature or fix.
+We suggest that the name of the branch be separated with hyphens and be concise with what you want to solve, it does not
+have to start with the word feature or fix.
 
 Which branch:
+
 * Make your pull request target master.
 
 ### Step 4: Make the changes
 
-You could follow this [guide](https://github.com/bancolombia/scaffold-clean-architecture/wiki/Implementing-or-changing-a-module)
+You could follow
+this [guide](https://github.com/bancolombia/scaffold-clean-architecture/wiki/Implementing-or-changing-a-module)
 
 ### Pull request criteria
 
@@ -72,46 +79,62 @@ You could follow this [guide](https://github.com/bancolombia/scaffold-clean-arch
 * Also, look at the GitHub's Pull Request guide
 
 ### General info
+
 * Comment on issues or pull requests.
 * Please suggest changes to documentation when you find something unclear.
-* You can create a fork of Scaffolding project in no time. Go to the github project and "Create your own fork". Create a new branch, commit, ..., when you're ready let us know about your pull request so we can discuss it and merge the PR!
+* You can create a fork of Scaffolding project in no time. Go to the github project and "Create your own fork". Create a
+  new branch, commit, ..., when you're ready let us know about your pull request so we can discuss it and merge the PR!
 
 ### More on pull requests
 
-The  Scaffolding project has now a continuous release bot, that means that each merged pull request will be automatically released in a newer version of the plugin. For that reason each pull request has to go through a thorough review and/or discussion.
+The Scaffolding project has now a continuous release bot, that means that each merged pull request will be automatically
+released in a newer version of the plugin. For that reason each pull request has to go through a thorough review and/or
+discussion.
 
 Things we pay attention in a PR :
 
 * On pull requests, please document the change, what it brings, what is the benefit.
-* Clean commit history in the topic branch in your fork of the repository, even during review. That means that commits are rebased and squashed if necessary, so that each commit clearly changes one things and there are no extraneous fix-ups.
+* Clean commit history in the topic branch in your fork of the repository, even during review. That means that commits
+  are rebased and squashed if necessary, so that each commit clearly changes one things and there are no extraneous
+  fix-ups.
 * In the code, always test your feature / change, in unit tests.
 
 #### UpgradeAction
-From version 2.3.0 you should implement an UpgradeAction, this implementation will be required if you had changed any structural file like:
+
+From version 2.3.0 you should implement an UpgradeAction, this implementation will be required if you had changed any
+structural file like:
+
 - main.gradle
 - build.gradle
 - applications/app-service/build.gradle
 - gradle.properties
 - other similar
 
-This upgrade action is intended to keep upgraded the projects that have been created with a previous plugin version, allowing it to be able to have the new features by simple running the `gradle updateCleanArchitecture` task.
+This upgrade action is intended to keep upgraded the projects that have been created with a previous plugin version,
+allowing it to be able to have the new features by simple running the `gradle updateCleanArchitecture` task.
 
-The UpgradeAction should be implemented in the package `co.com.bancolombia.factory.upgrades.actions` and should have an specific date based name, which allows that the update occurs in the order which it is created.
+The UpgradeAction should be implemented in the package `co.com.bancolombia.factory.upgrades.actions` and should have an
+specific date based name, which allows that the update occurs in the order which it is created.
 
 The standard is UpgradeY(year)M(month)D(day of month)
 
 If your pull request have structural changes and it does not comes with an UpgradeAction, it will be rejected.
 
 #### New Tasks
-If your contribution will have new tasks, you can use one of the existing abstractions, and you should use the annotation @CATask providing a name, description and a shortcut
+
+If your contribution will have new tasks, you can use one of the existing abstractions, and you should use the
+annotation @CATask providing a name, description and a shortcut
+
 - [AbstractCleanArchitectureDefaultTask](https://github.com/bancolombia/scaffold-clean-architecture/blob/master/src/main/java/co/com/bancolombia/task/AbstractCleanArchitectureDefaultTask.java)
 - [AbstractResolvableTypeTask](https://github.com/bancolombia/scaffold-clean-architecture/blob/master/src/main/java/co/com/bancolombia/task/AbstractCleanArchitectureDefaultTask.java)
 
 #### New Module Factories
 
-If your contribution has a new item of type DrivenAdapter, EntryPoint, PerformaceTest, AcceptanceTest, Helper or Pipeline these modules factories should be named and located following the next rule.
+If your contribution has a new item of type DrivenAdapter, EntryPoint, PerformaceTest, AcceptanceTest, Helper or
+Pipeline these modules factories should be named and located following the next rule.
 
-Name: Should contain the prefix of his type, for example DrivenAdapter -> DrivenAdapterR2DBC, project will infer the driven adapter type as `R2DBC`
+Name: Should contain the prefix of his type, for example DrivenAdapter -> DrivenAdapterR2DBC, project will infer the
+driven adapter type as `R2DBC`
 Package Location: Should be located in the corresponding package as you can see in the next table:
 
 | Type           | Package                                      |
@@ -129,16 +152,21 @@ Good commit messages serve at least three important purposes:
 
 - To speed up the reviewing process
 - To help us write a good release note
-  To help the future maintainers (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added.
+  To help the future maintainers (it could be you!), say five years into the future, to find out why a particular change
+  was made to the code or why a specific feature was added.
 
 Rules:
 
-1. You should use conventional commits, you can find more information [here](https://www.conventionalcommits.org/en/v1.0.0/)
-2. Write the summary line and description of what you have done in the imperative mood, that is as if you were commanding someone. Start the line with "Fix", "Add", "Change" instead of "Fixed", "Added", "Changed"
+1. You should use conventional commits, you can find more
+   information [here](https://www.conventionalcommits.org/en/v1.0.0/)
+2. Write the summary line and description of what you have done in the imperative mood, that is as if you were
+   commanding someone. Start the line with "Fix", "Add", "Change" instead of "Fixed", "Added", "Changed"
 3. Contain a short description of the change (preferably 50 characters or less, and no more than 72 characters)
-4. be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code, like function/variable names
+4. be entirely in lowercase with the exception of proper nouns, acronyms, and the words that refer to code, like
+   function/variable names
 5. Keep the second line blank.
-6. If your commit introduces a breaking change (semver-major), it should contain an explanation about the reason of the breaking change, which situation would trigger the breaking change and what is the exact change.
+6. If your commit introduces a breaking change (semver-major), it should contain an explanation about the reason of the
+   breaking change, which situation would trigger the breaking change and what is the exact change.
 7. Use the body to explain what and why vs. how
 
 For example:
@@ -202,7 +230,7 @@ When you will implement a new module related to infrastructure layer you should
    not reactive).
 
    |module type|resources path|
-   |----|---------------|
+                  |----|---------------|
    |Driven Adapter|resources/driven-adapter/\<module-name>(-reactive)|
    |Entry Point|resources/entry-point/\<module-name>(-reactive)|
    |Helper|resources/helper/\<module-name>(-reactive)|
@@ -212,7 +240,7 @@ When you will implement a new module related to infrastructure layer you should
 2. Implement the ModuleFactory for the new module type in the correct package.
 
    |module type|package|
-   |----|---------------|
+                  |----|---------------|
    |Driven Adapter|co.com.bancolombia.factory.adapters|
    |Entry Point|co.com.bancolombia.factory.entrypoints|
    |Helper|co.com.bancolombia.factory.helpers|
@@ -300,7 +328,7 @@ The next code adds the property `spring.datasource.url=jdbc:h2:mem:test` and the
 3. Add the type of module in the correct enum.
 
    |module type|enum|
-   |----|---------------|
+         |----|---------------|
    |Driven Adapter|co.com.bancolombia.factory.adapters.ModuleFactoryDrivenAdapter.DrivenAdapterType|
    |Entry Point|co.com.bancolombia.factory.entrypoints.ModuleFactory.EntryPoint|
    |Helper|co.com.bancolombia.factory.helpers.ModuleFactoryHelpers.EntryPointType|
@@ -310,7 +338,7 @@ The next code adds the property `spring.datasource.url=jdbc:h2:mem:test` and the
 4. Add the instantiation block in the correct class according to the new type.
 
    |module type|factory class|
-   |----|---------------|
+         |----|---------------|
    |Driven Adapter|co.com.bancolombia.factory.adapters.ModuleFactoryDrivenAdapter|
    |Entry Point|co.com.bancolombia.factory.entrypoints.ModuleFactory|
    |Helper|co.com.bancolombia.factory.helpers.ModuleFactoryHelpers|
@@ -360,7 +388,7 @@ To achieve it you have two options:
 
   Create a build.gradle file in an empty folder with the next content:
 
-     ```gradle
+     ```groovy
      buildscript {
          repositories {
             mavenLocal()
@@ -380,14 +408,14 @@ To achieve it you have two options:
 
   Create a build.gradle file in an empty folder with the next content:
 
-     ```gradle
+     ```groovy
      plugins {
          id "co.com.bancolombia.cleanArchitecture" version "2.4.1.1"
      }
      ```
   Create a settings.gradle file in an empty folder with the next content:
 
-     ```gradle
+     ```groovy
      pluginManagement {
          repositories {
              mavenLocal()

diff --git a/docs/docs/advanced/2-use-as-updater.md b/docs/docs/advanced/2-use-as-updater.md
@@ -15,7 +15,7 @@ This task is the created for that, and you can use it by following the next step
 1. Add plugin to your `build.gradle` project file as described in the [Getting Started](/docs/2-getting-started.md)
    section.
 2. Add the following property to your `gradle.properties` file
-   like [commons-jms](https://github.com/bancolombia/commons-jms) project
+   like [commons-jms](https://github.com/bancolombia/commons-jms/blob/main/gradle.properties) project
 
 ```properties
 onlyUpdater=true