DEV Community: Query Filter

gradle-60

Query Filter — Thu, 30 Jul 2026 20:02:32 +0000

tasks.register("listRepos") {
    doLast {
        allprojects { p ->
            println("\nProject: ${p.name}")
            println("--- Project Repositories ---")
            p.repositories.each { repo ->
                if (repo.hasProperty('url')) {
                    println("  ${repo.name}: ${repo.url}")
                }
            }
            println("--- Buildscript Repositories ---")
            p.buildscript.repositories.each { repo ->
                if (repo.hasProperty('url')) {
                    println("  ${repo.name}: ${repo.url}")
                }
            }
        }
    }
}

gradle-59

Query Filter — Thu, 30 Jul 2026 19:59:36 +0000

tasks.register("listRepos") {
    doLast {
        allprojects {
            println("\nProject: $name")
            println("--- Project Repositories ---")
            repositories.forEach { repo ->
                if (repo is MavenArtifactRepository) println("  ${repo.name}: ${repo.url}")
            }
            println("--- Buildscript Repositories ---")
            buildscript.repositories.forEach { repo ->
                if (repo is MavenArtifactRepository) println("  ${repo.name}: ${repo.url}")
            }
        }
    }
}

gradle-58

Query Filter — Thu, 30 Jul 2026 16:37:12 +0000

git clone https://github.com/CitiInternal/165889.ui-platform.ui-platform-docs.git

gradle-57

Query Filter — Thu, 30 Jul 2026 16:22:29 +0000

powershell -Command "(Invoke-WebRequest -Uri 'https://example.com/page').ParsedHtml.body.innerText" > output.txt

gradle-56

Query Filter — Wed, 29 Jul 2026 19:59:44 +0000

public enum EodFlowType {
    ORDER_EXECUTION(""),
    RFQ(":RFQ"),
    RISK_BREACH(":RISKBREACH"); // or ":RISK_BREACH" depending on requirements

    private final String regionSuffix;

    EodFlowType(String regionSuffix) {
        this.regionSuffix = regionSuffix;
    }

    public String regionSuffix() {
        return regionSuffix;
    }
}

gradle-55

Query Filter — Wed, 29 Jul 2026 17:01:38 +0000

gradle-54

Query Filter — Wed, 29 Jul 2026 16:50:33 +0000

gradle-53

Query Filter — Wed, 29 Jul 2026 16:35:01 +0000

Implementation AreaRequirements/ContextAction RequiredApp Directory / Citi Desktop Portal (AppD) PermissionsSupport groups are being configured in the application permissions interface. A clarification was requested on whether granting access to support groups permits them to approve core application code and operational deployments (e.g., UAT to Production code changes), or if access is restricted to desktop platform metadata. It was confirmed that AppD permissions strictly govern the publishing, visibility, and catalog promotion of the desktop application listing on the AppD portal, having no impact on actual backend application code or infrastructure pipeline deployments.Assign the required support groups to the AppD permissions tab to enable them to manage, promote, and publish desktop catalog updates and launch configurations.Maintain all core application code, GUI updates, and environment configuration changes strictly within the primary build and deployment pipelines (e.g., Tekton / Harness / CI-CD).

bridge-46

Query Filter — Mon, 27 Jul 2026 15:00:42 +0000

gradle-52

Query Filter — Wed, 22 Jul 2026 20:30:25 +0000

To clean up your build configuration and strip out heavy "fat" dependencies while keeping only what your codebase actually imports, you can use a combination of Gradle's built-in dependency analysis tools and the gradle-dependency-analysis-plugin.

Here is a step-by-step approach to audit, isolate, and cull unnecessary dependencies in Gradle 7.5.

Step 1: Run the Built-In Dependency Insight
Before removing anything, run Gradle’s dependency insight report to identify why a heavy transitive library is being pulled into your build graph and which top-level dependency introduced it.

In your terminal, run:

Bash
./gradlew dependencyInsight --dependency --configuration compileClasspath
This generates a dependency tree showing the exact path from your build.gradle declaration down to the nested artifact.

Step 2: Use the Dependency Analysis Plugin (Automated Audit)
The most accurate way to find unused direct dependencies (and indirect dependencies you should declare explicitly) is Autonomous Apps' dependency-analysis-gradle-plugin. It scans your bytecode against your declared dependency graph.

Add it to your root build.gradle:

Groovy
plugins {
id 'com.autonomousapps.dependency-analysis' version '1.19.0' // Fully compatible with Gradle 7.5
}
Then run the audit task:

Bash
./gradlew buildHealth
What the report tells you:
Unused dependencies: Libraries declared in dependencies { ... } that your source code never references. You can delete these immediately.

Transitively used dependencies: Libraries drawn in by a "big" parent library that your code does reference directly.

Undeclared dependencies: Dependencies you rely on in code but only have access to because another library drew them in.

Step 3: Cull the Big Library & Promote the Transitive Artifact
Once you identify that you only use a small sub-module or underlying transitive dependency from a heavy framework:

Option A: Replace the Parent Library with the Specific Module
Many large frameworks (like AWS SDK, Jackson, Spring, or Google Guava/GCP) split their functionality into smaller artifacts. Instead of pulling in the top-level bundle, replace it with only the required sub-module.

Groovy
dependencies {
// ❌ Heavy bundle
// implementation 'com.amazonaws:aws-java-sdk:1.12.xxx'

// ✅ Specific modular artifact
implementation 'com.amazonaws:aws-java-sdk-s3:1.12.xxx'

}
Option B: Exclude the Heavy Parent and Declare the Sub-Dependency
If a library pulls in heavy transitive dependencies you don't want (like logging frameworks, UI tools, or large utility suites), explicitly exclude them:

Groovy
dependencies {
implementation('com.example:some-library:2.1.0') {
// Exclude the heavy transitive artifact
exclude group: 'org.heavy.framework', module: 'heavy-core'
}

// Explicitly declare ONLY the lightweight sub-dependency your code actually uses
implementation 'org.heavy.framework:lightweight-utils:1.0.0'

}
Step 4: Use Gradle Constraints for Version Control
When you strip out a top-level library and explicitly declare its underlying transitive library, use constraints to manage the version cleanly without locking yourself into rigid hardcodes:

Groovy
dependencies {
constraints {
implementation('net.bytebuddy:byte-buddy:1.14.12') {
because 'Explicitly managed version after removing parent library'
}
}

// Direct lightweight declaration
implementation 'net.bytebuddy:byte-buddy'

}
Summary Checklist
Run ./gradlew buildHealth to get a list of Unused and Transitively Used dependencies.

Delete all Unused lines from dependencies { }.

For Transitively Used dependencies, add the specific lower-level artifact directly to dependencies { } and remove the top-level parent library.

Run ./gradlew test to ensure your runtime classpath remains intact.

gradle-51

Query Filter — Wed, 22 Jul 2026 20:28:49 +0000

To clean up your build configuration and strip out heavy "fat" dependencies while keeping only what your codebase actually imports, you can use a combination of **Gradle's built-in dependency analysis tools** and the **`gradle-dependency-analysis-plugin`**.

Here is a step-by-step approach to audit, isolate, and cull unnecessary dependencies in **Gradle 7.5**.

---

## Step 1: Run the Built-In Dependency Insight

Before removing anything, run Gradle’s dependency insight report to identify **why** a heavy transitive library is being pulled into your build graph and **which top-level dependency** introduced it.

In your terminal, run:

bash
./gradlew dependencyInsight --dependency --configuration compileClasspath


This generates a dependency tree showing the exact path from your `build.gradle` declaration down to the nested artifact.

---

## Step 2: Use the Dependency Analysis Plugin (Automated Audit)

The most accurate way to find unused direct dependencies (and indirect dependencies you *should* declare explicitly) is Autonomous Apps' **`dependency-analysis-gradle-plugin`**. It scans your bytecode against your declared dependency graph.

Add it to your root `build.gradle`:

groovy
plugins {
id 'com.autonomousapps.dependency-analysis' version '1.19.0' // Fully compatible with Gradle 7.5
}


Then run the audit task:

bash
./gradlew buildHealth


### What the report tells you:

1. **Unused dependencies:** Libraries declared in `dependencies { ... }` that your source code never references. You can delete these immediately.
2. **Transitively used dependencies:** Libraries drawn in by a "big" parent library that your code *does* reference directly.
3. **Undeclared dependencies:** Dependencies you rely on in code but only have access to because another library drew them in.

---

## Step 3: Cull the Big Library & Promote the Transitive Artifact

Once you identify that you only use a small sub-module or underlying transitive dependency from a heavy framework:

### Option A: Replace the Parent Library with the Specific Module

Many large frameworks (like AWS SDK, Jackson, Spring, or Google Guava/GCP) split their functionality into smaller artifacts. Instead of pulling in the top-level bundle, replace it with only the required sub-module.

groovy
dependencies {
// ❌ Heavy bundle
// implementation 'com.amazonaws:aws-java-sdk:1.12.xxx'

// ✅ Specific modular artifact
implementation 'com.amazonaws:aws-java-sdk-s3:1.12.xxx'

}


### Option B: Exclude the Heavy Parent and Declare the Sub-Dependency

If a library pulls in heavy transitive dependencies you *don't* want (like logging frameworks, UI tools, or large utility suites), explicitly exclude them:

groovy
dependencies {
implementation('com.example:some-library:2.1.0') {
// Exclude the heavy transitive artifact
exclude group: 'org.heavy.framework', module: 'heavy-core'
}

// Explicitly declare ONLY the lightweight sub-dependency your code actually uses
implementation 'org.heavy.framework:lightweight-utils:1.0.0'

}


---

## Step 4: Use Gradle Constraints for Version Control

When you strip out a top-level library and explicitly declare its underlying transitive library, use `constraints` to manage the version cleanly without locking yourself into rigid hardcodes:

groovy
dependencies {
constraints {
implementation('net.bytebuddy:byte-buddy:1.14.12') {
because 'Explicitly managed version after removing parent library'
}
}

// Direct lightweight declaration
implementation 'net.bytebuddy:byte-buddy'

}


---

## Summary Checklist

1. Run `./gradlew buildHealth` to get a list of **Unused** and **Transitively Used** dependencies.
2. Delete all **Unused** lines from `dependencies { }`.
3. For **Transitively Used** dependencies, add the specific lower-level artifact directly to `dependencies { }` and remove the top-level parent library.
4. Run `./gradlew test` to ensure your runtime classpath remains intact.

gradle-50

Query Filter — Wed, 22 Jul 2026 16:35:40 +0000

<!DOCTYPE html>
<html>
<head>
<style>
    body {
        font-family: Arial, sans-serif;
        color: #333333;
        line-height: 1.5;
    }
    h2 {
        color: #003366;
        border-bottom: 2px solid #003366;
        padding-bottom: 4px;
        margin-top: 20px;
    }
    h3 {
        color: #005599;
        margin-top: 15px;
    }
    table {
        width: 100%;
        border-collapse: collapse;
        margin: 15px 0;
        font-size: 14px;
    }
    th {
        background-color: #003366;
        color: #ffffff;
        text-align: left;
        padding: 8px 12px;
        border: 1px solid #003366;
    }
    td {
        padding: 8px 12px;
        border: 1px solid #cccccc;
    }
    tr:nth-child(even) {
        background-color: #f9f9f9;
    }
    ul {
        margin-top: 5px;
        padding-left: 20px;
    }
    li {
        margin-bottom: 6px;
    }
</style>
</head>
<body>

<h2>4. Build & Deployment Architecture</h2>

<h3>4.1 Build and Deployment Strategy Matrix</h3>
<p>To support the migration to LightSpeed Enterprise while maintaining operational stability, system builds and deployments are partitioned by component architecture:</p>

<table>
    <thead>
        <tr>
            <th>Component Category</th>
            <th>Target Platform / Environment</th>
            <th>CI / Build Engine</th>
            <th>CD / Deployment Orchestration</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td><strong>Comet GUI</strong></td>
            <td>Legacy / Managed Host</td>
            <td>TeamCity</td>
            <td>uDeploy</td>
        </tr>
        <tr>
            <td><strong>Non-GUI Back-End Applications</strong></td>
            <td>LightSpeed Enterprise</td>
            <td>Tekton</td>
            <td>Harness / Ansible Suite</td>
        </tr>
    </tbody>
</table>

<h3>4.2 Application Integration & Migration Path</h3>
<ul>
    <li><strong>Comet GUI Subsystem:</strong>
        <ul>
            <li><strong>Build Pipeline:</strong> TeamCity remains the designated CI tool responsible for building, testing, and packaging the Comet GUI application artifacts.</li>
            <li><strong>Deployment Pipeline:</strong> uDeploy retains sole responsibility for triggering and orchestrating GUI application deployments across target environments.</li>
        </ul>
    </li>
    <li><strong>Non-GUI Back-End Services:</strong>
        <ul>
            <li><strong>Platform Target:</strong> All non-GUI backend applications are designated for migration to <strong>LightSpeed Enterprise</strong>.</li>
            <li><strong>Build Pipeline:</strong> Tekton serves as the cloud-native CI engine to execute automated container builds, unit tests, and artifact publishing.</li>
            <li><strong>Deployment & Provisioning Pipeline:</strong> Continuous delivery and infrastructure configuration are managed via the integrated <strong>Harness / Ansible</strong> suite to handle enterprise-grade deployment orchestration and configuration management.</li>
        </ul>
    </li>
</ul>

</body>
</html>