# dependency-management Published articles for dependency-management. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How the Gradle Team Adopted Isolated Projects DevFeed: [How the Gradle Team Adopted Isolated Projects]() Original publisher: [Read original article]() Author: Alex Semin Published: 2026-07-22T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Scalability](), [Cache](), [configuration](), [Dependency management](), [ci](), [ide]() Tags: [cache](), [ci](), [configuration](), [dependency-management](), [gradle](), [ide](), [parallelism](), [performance]() ### AI overview The Gradle team describes adopting the experimental Isolated Projects feature in its own build. The article explains that Isolated Projects runs project configuration in parallel to improve scalability and performance, and outlines migration prerequisites, diagnostics, convention plugins, dependency management, and Shared Build Services. ### Source excerpt Isolated Projects is an experimental feature aimed at improving Gradle scalability and performance. It speeds up builds by running project configuration in parallel, which benefits practically every workflow, from CI builds to IDE sync. We want the feature to offer an excellent user experience, so we made it a goal to adopt Isolated Projects in our own build, even though it is still in active development. This lets us find and smooth out the rough spots early, though secretly, we were also looking forward to the productivity boost for our own team. With Isolated Projects, more build logic runs concurrently. To keep builds reliable under that parallelism, the feature introduces additional constraints, and adopting it means migrating your build to address the violations of those constraints. Migrating our build Isolated Projects builds directly on top of the Configuration Cache, so making the build Configuration Cache compatible is a prerequisite. Fortunately for us, we've been enjoying fast inner developer loops for many years now, so that box was already checked. The general approach to migrating against new constraints is to start with the simplest workflows, such as running the help task, and address the violations. Then proceed to more complex workflows, such as IDE sync or CI. Running in Diagnostics mode helps you see all violations at once in a single HTML report, and the guide describes the recommended migration path. For the Gradle build, we followed a similar path. What helped us the most and made the migration much smoother is following the best practices, especially the best practice of having convention plugins: each project applies the build logic it needs, and no project has to reach in and mutate another's state directly. We've leaned heavily on sharing artifacts between projects only via dependency management, which is inherently compatible with Isolated Projects by making each project define its "outputs", on which other projects can depend. For more ## CEL repositories move to the dedicated cel-expr GitHub organization DevFeed: [CEL repositories move to the dedicated cel-expr GitHub organization]() Original publisher: [Read original article]() Author: Google Open Source (noreply@blogger.com) Published: 2026-06-16T18:30:00Z Content type: release Language: en Sources: [Google Open Source Blog]() Topics: [GitHub](), [Git]() Tags: [announce](), [brand-identity](), [c-plus-plus](), [cel](), [common-expression-language](), [consistency](), [dependencies](), [dependency-management](), [development](), [discoverability](), [github](), [go](), [java](), [pull-requests](), [python]() ### AI overview The official Common Expression Language (CEL) repositories have moved from the Google organization to the dedicated cel-expr GitHub organization. The move centralizes the language specification and implementations, while redirects preserve existing links and repository history. ### Source excerpt by Olena Huang, CEL (Common Expression Language) team We're excited to announce that the official Common Expression Language (CEL) repositories have moved to a dedicated GitHub organization. Visit the new cel-expr repository now! Why the move? This move is a key step in strengthening the CEL ecosystem. By centralizing our projects, including the language specification, Go, C++, C, Java, and Python implementations, under the cel-expr organization, we aim to: Enhance Branding: Create a clear and unified brand identity for CEL. Improve Discoverability: Make it easier for users and contributors to find all official CEL resources in one place. Ensure Consistency: Foster consistency across all CEL projects. Streamline Development: Simplify our development and release processes. What's Changing? The following repositories now reside in the cel-expr organization: google/cel-spec is now cel-expr/cel-spec google/cel-cpp is now cel-expr/cel-cpp google/cel-go is now cel-expr/cel-go google/cel-java is now cel-expr/cel-java cel-expr/cel-python and cel-expr/cel-c have already been in the cel-expr namespace All future development, issues, and pull requests for these projects will take place in their new homes within the cel-expr organization. This is a non-breaking change, due to automatic redirects, but you should update your URLs where possible. What Stays the Same? We've worked to make this transition as seamless as possible: Automatic Redirects: GitHub will automatically redirect all web traffic and git operations from the old google/cel-* URLs to the new cel-expr/cel-* locations. Your existing links and git remote configurations pointing to the old URLs should continue to work for cloning and fetching. Preserved History: The full commit history, issues, and pull requests for each repository have been migrated and are available in the new locations. Action Required: Update Your Dependencies While existing links and git remote configurations pointing to the old URLs should conti ## Hilt in Android Auto: From Manual Factories to a Cleaner Screen Provider DevFeed: [Hilt in Android Auto: From Manual Factories to a Cleaner Screen Provider]() Original publisher: [Read original article]() Author: FunkyMuse Published: 2026-06-05T09:30:00Z Content type: tutorial Language: en Sources: [FunkyMuse]() Topics: [Android](), [Dagger](), [Dependency management](), [App](), [Testing]() Tags: [android](), [android-auto](), [dagger](), [dependency-management](), [di](), [how-to](), [testing]() ### AI overview A tutorial on replacing manual dependency wiring in an Android Auto Car App with compile-time dependency injection using Hilt. It explains using Hilt entry points, screen providers, multibinding, and a central module to reduce constructor boilerplate and improve testability. ### Source excerpt If you've ever followed the Android Auto Codelabs, you've seen the "sample" way of building a Car App. It works, it's functional, but as soon as you try to scale it beyond a simple demo, you hit a wall: Dependency Management. Keep in mind this is only one way to wire things, I'm pretty sure many others exist, I'm exploring things on Android Auto and Android Wear lately and how to connect and w... ## Flutter 3.44 will make Swift Package Manager the default for iOS and macOS apps DevFeed: [Flutter 3.44 will make Swift Package Manager the default for iOS and macOS apps]() Original publisher: [Read original article]() Author: Jenn Magder Published: 2026-04-30T15:57:00Z Content type: release Language: en Sources: [Flutter - Medium]() Topics: [Flutter](), [Dependency management](), [Swift](), [iOS](), [macOS](), [Package manager](), [Command-line interface](), [Xcode]() Tags: [cli](), [cocoapods](), [dependencies](), [dependency-management](), [flutter](), [flutter-app-development](), [ios](), [macos](), [migration](), [release](), [swift](), [swift-package-manager](), [xcode]() ### AI overview Flutter 3.44 will make Swift Package Manager the default dependency manager for iOS and macOS apps, replacing CocoaPods. The Flutter CLI will migrate projects automatically, temporarily fall back to CocoaPods for unsupported plugins, and allow developers to opt out if SwiftPM causes breaking issues. ### Source excerpt Dash migration! Starting with the next stable Flutter release, 3.44, Swift Package Manager (SwiftPM) replaces CocoaPods as the default dependency manager for iOS and macOS apps. This means no more messing around with Ruby or CocoaPods installations just to get your app running! CocoaPods is officially in maintenance mode, and its registry will permanently become read-only on December 2, 2026. While existing builds will still work, no new versions or pods will be added to the trunk after this date. To ensure that your apps continue receiving dependency updates and to provide access to the Swift package ecosystem, Flutter is transitioning to Apple's supported dependency management solution: Swift Package Manager. If you've already migrated your plugin(s) to use SwiftPM, read the "Plugin developers" section below for new migration requirements. Here is how to manage the transition. App developers For app developers, the Flutter CLI handles the migration. When you run or build your iOS or macOS app, the CLI automatically updates your Xcode project to use Swift Package Manager. Check out the Flutter migration docs for app developers for more details. If your app relies on plugins that haven't adopted Swift Package Manager yet, Flutter will print a warning listing exactly which of your dependencies are unsupported. Flutter will temporarily fall back to CocoaPods for plugins that have not adopted Swift packages yet. Because CocoaPods support will eventually be removed entirely, if a plugin hasn't updated and breaks your build, file an issue with the dependency's maintainer to request Swift package support or find an alternative package. We know that migrations can sometimes hit a snag. If SwiftPM causes a breaking issue, you can temporarily disable it for your project. Open your pubspec.yaml file, navigate to the flutter section, and set enable-swift-package-manager to false under the config block: flutter: config: enable-swift-package-manager: false If you opt out, please ## Lessons from Software Engineering at Google for Maintaining Healthy Codebases DevFeed: [Lessons from Software Engineering at Google for Maintaining Healthy Codebases]() Original publisher: [Read original article]() Author: Dr Milan Milanović Published: 2026-02-26T16:01:23Z Content type: opinion Language: en Sources: [Tech World With Milan Newsletter]() Topics: [Software Engineering](), [Development](), [Dependency management](), [Code review](), [Refactoring](), [engineering-culture](), [Mocking](), [releases](), [upgrade]() Tags: [code-review](), [dependency-management](), [engineering](), [leadership](), [mocking](), [release](), [software-engineering]() ### AI overview A review of Software Engineering at Google argues that the book's lessons apply to teams of different sizes. It highlights practices for evolving, sharing, testing, releasing, and eventually deleting code, along with code review, dependency management, productivity measurement, and engineering culture. ### Source excerpt And what you can apply from today. ## Migrating from Nav2 to Nav3 DevFeed: [Migrating from Nav2 to Nav3]() Original publisher: [Read original article]() Published: 2026-02-23T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [migration](), [Compose](), [Dependency management](), [interface](), [Library]() Tags: [compose](), [dependencies](), [dependency-management](), [guide](), [how-to](), [interface](), [migrate](), [migration-guide](), [workshop-learning-programming]() ### AI overview A practical guide to migrating a Compose navigation setup from Nav2 to Nav3. It covers adding dependencies, updating destinations to use NavKey, and migrating NavHosts incrementally while preserving the existing navigation during the transition. ### Source excerpt How to migrate routes, navigation calls, and transitions from Nav2 to Nav3. ## JavaScript's dependency ecosystem needs stronger supply-chain security and package management DevFeed: [JavaScript's dependency ecosystem needs stronger supply-chain security and package management]() Original publisher: [Read original article]() Author: September Published: 2025-09-17T00:00:00Z Content type: opinion Language: en Sources: [Drew DeVault]() Topics: [JavaScript](), [Package Management](), [npm](), [Linux]() Tags: [dependency-management](), [javascript](), [linux](), [npm](), [reproducible-builds](), [supply-chain]() ### AI overview This opinion article argues that JavaScript's dependency ecosystem should respond to supply-chain attacks by reducing sprawling dependency trees and adopting stronger trust, package-signing, distribution, and reproducible-build practices. It also proposes a standard library and more consolidated packages. ### Source excerpt In the wake of the largest supply-chain attack in history, the JavaScript community could have a moment of reckoning and decide: never again. As the panic and shame subsides, after compromised developers finish re-provisioning their workstations and rotating their keys, the ecosystem might re-orient itself towards solving the fundamental flaws that allowed this to happen. After all, people have been sounding the alarm for years that this approach to dependency management is reckless and dangerous and broken by design. Maybe this is the moment when the JavaScript ecosystem begins to understand the importance and urgency of this problem, and begins its course correction. It could leave behind its sprawling dependency trees full of micro-libraries, establish software distribution based on relationships of trust, and incorporate the decades of research and innovation established by more serious dependency management systems. Perhaps Google and Mozilla, leaders in JavaScript standards and implementations, will start developing a real standard library for JavaScript, which makes micro-dependencies like left-pad a thing of the past. This could be combined with a consolidation of efforts, merging micro-libraries into larger packages with a more coherent and holistic scope and purpose, which prune their own dependency trees in turn. This could be the moment where npm comes to terms with its broken design, and with a well-funded effort (recall that, ultimately, npm is GitHub is Microsoft, market cap $3 trillion USD), will develop and roll out the next generation of package management for JavaScript. It could incorporate the practices developed and proven in Linux distributions, which rarely suffer from these sorts of attacks, by de-coupling development from packaging and distribution, establishing package maintainers who assemble and distribute curated collections of software libraries. By introducing universal signatures for packages of executable code, smaller channels and ## When do you really need a monorepo? DevFeed: [When do you really need a monorepo?]() Original publisher: [Read original article]() Author: Emma Adler Published: 2025-02-26T00:00:00Z Content type: tutorial Language: en Sources: [Mintlify Blog]() Topics: [monorepo](), [Software Engineering](), [Dependency management](), [build performance](), [CI/CD]() Tags: [best-practices](), [build-performance](), [ci-cd](), [code](), [collaboration](), [dependency-management](), [documentation](), [monorepo](), [software-engineering]() ### AI overview This guide helps software engineering teams choose between monorepo and multi-repo strategies. It compares code sharing, dependency management, build performance, CI/CD pipelines, documentation consistency, collaboration, and access control, while describing how large organizations use monorepos. ### Source excerpt Software engineering teams often face an important decision: "Should all projects live in one repository or be split across multiple repositories?" This decision impacts build times, CI/CD pipelines, dependency management, and even documentation accuracy. ## Undisclosed bundled dependencies in Kotlin compiler POM metadata DevFeed: [Undisclosed bundled dependencies in Kotlin compiler POM metadata]() Original publisher: [Read original article]() Author: Tony Robalik Published: 2025-02-07T23:54:47Z Content type: opinion Language: en Sources: [DEV Community: Tony Robalik]() Topics: [Dependency management](), [Java](), [Kotlin](), [Gradle]() Tags: [coding](), [community](), [dependency-management](), [development](), [engineering](), [gradle](), [inclusive](), [java](), [jvm](), [kotlin](), [software]() ### AI overview The author investigates a JVM ClassCastException and traces it to the Kotlin compiler JAR loaded by Gradle. They argue that bundled, unrelocated Guava classes and POM metadata that does not disclose the fat JAR create dependency-management problems. ### Source excerpt Photo by Marco Bicca on Unsplash. I really hope there's a light at the end of this sewer. Sorry, my country is dissolving into a Nazi sewer of world-historical proportions and so I'm dealing with my otherwise fruitless rage by yelling about JVM things. The fact that Java classes exist in a global namespace is not well-appreciated, even by vendors of major parts of the ecosystem (apparently). Caused by: java.lang.ClassCastException: class com.google.common.graph.ImmutableGraph cannot be cast to class com.google.common.graph.SuccessorsFunction (com.google.common.graph.ImmutableGraph and com.google.common.graph.SuccessorsFunction are in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader$InstrumentingVisitableURLClassLoader @4617120) A confusing error at the best of times, but to a build engineer (i.e. me) trying to help out during a SEV, a despair-inducing example of how Dependency Management on the JVM is Completely Broken, What Are We Even Doing Here. A ClassCastException always means Someone Somewhere Hates You, or at least values their own KPIs more than not polluting the entire goddamn ecosystem. Let's debug! My first step is to navigate to the Graph class and check its hierarchy. I can confirm that, yes, in Guava 33.3.1-jre at least, that class does indeed implement the SuccessorsFunction interface. It should not be throwing a ClassCastException! Next step. In Intellij (the vendor which is ironically the source of this amongst most of the rest of my woes), I set a breakpoint at the exception and evaluate the following expression.1 // `this` is an instance of the `com.google.common.graph.Graph` class this.javaClass.superclass.superclass.superclass.interfaces.first().protectionDomain.codeSource.location That expression resolves to this: file:/Users/<>/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-compiler/2.0.21/88f09afc2536e38d528e78eb8349504de10ac436/kotlin-compiler-2.0.21.jar What the fuck! That is not the righ ## Heroku CLI v9: Infrastructure Upgrades and oclif Transition DevFeed: [Heroku CLI v9: Infrastructure Upgrades and oclif Transition]() Original publisher: [Read original article]() Author: Anush DSouza Published: 2024-07-25T01:55:03Z Content type: release Language: en Sources: [Heroku]() Topics: [Command-line interface](), [Heroku](), [upgrade](), [Architecture & Design](), [Dependency management](), [Testing](), [legacy](), [maintenance](), [telemetry]() Tags: [architecture](), [cli](), [dependency-management](), [developer-tools](), [engineering](), [framework](), [heroku](), [legacy](), [maintenance](), [release](), [telemetry](), [testing](), [upgrades]() ### AI overview Heroku CLI v9.0.0 restructures the core CLI around the oclif platform, consolidates core commands into one package, improves testing and release automation, and adds telemetry. The release also introduces breaking changes to output formatting, flags, arguments, and deprecated commands. ### Source excerpt Introduction The Heroku CLI is an incredible tool. It's simple, extendable, and allows you to interact with all the Heroku functionality you depend on day to day. For this reason, it's incredibly important for us to keep it up to date. Today, we're excited to highlight a major upgrade with the release of Heroku CLI [...] The post Heroku CLI v9: Infrastructure Upgrades and oclif Transition appeared first on Heroku. ## Dependency Management - Best Practices for Naming Gradle Version Catalog Entries DevFeed: [Dependency Management - Best Practices for Naming Gradle Version Catalog Entries]() Original publisher: [Read original article]() Author: Benedikt Ritter Published: 2024-07-08T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Dependency management]() Tags: [best-practices](), [blog-post](), [dependency-management](), [gradle]() ### AI overview This article explains how Gradle version catalogs standardize dependency definitions and describes the Develocity team's conventions for naming catalog entries based on GAV coordinates. It also shows how catalog entries generate compile-safe dependency accessors. ### Source excerpt Version catalogs are a fairly recent feature in Gradle Build Tool. They help manage dependencies by providing a standardized way of defining and accessing the catalog of dependencies used in a project--ensuring that all developers in a team are aligned on dependency names and definitions saves time and cognitive load for everyone. Like most Gradle features they are quite flexible, so users have to come up with their own conventions for how to use them. In this blog post, we're going to share some of the best-practices we employ in the Develocity team when it comes to managing dependencies using version catalogs. In particular, we're going to look at our convention for how to derive a version catalog entry name from the GAV (short for Group, Artifact ID, Version) coordinates of a particular dependency. Version catalogs Version catalogs are part of Gradle's dependency management features. They provide a convenient, standardized way to define a set of dependencies that are available to engineers in the project. Version catalogs can either be defined directly in Gradle's settings script, or using a separate TOML file. The default for a TOML catalog is to place it in gradle/libs.versions.toml. This will create a libs catalog to be used in the build. An example entry in TOML format can look like this: commons-lang3 = { module = "org.apache.commons:commons-lang3", version = "3.14.0" } When Gradle finds a version catalog, it generates accessors that can be used in the build scripts to define dependencies in a compile-safe way. So instead of writing: implementation("org.apache.commons:commons-lang3:3.14.0") And repeating the GAV coordinate string in each of the build scripts where we need this dependency, we can now write: implementation(libs.commons.lang3) As we can see from this example there are some rules that Gradle applies while translating from the catalog entry commons-lang3 to the accessor libs.commons.lang3. Furthermore a question that we could be asking is why I ca ## Road to Gradle 9 with Louis Jacomet DevFeed: [Road to Gradle 9 with Louis Jacomet]() Original publisher: [Read original article]() Author: Oleg Nenashev Published: 2024-06-18T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Maven](), [Dependency management](), [Cache](), [configuration](), [Java](), [Kotlin]() Tags: [build-tool](), [cache](), [compatibility](), [configuration](), [dependency-management](), [github](), [gradle](), [kotlin](), [performance]() ### AI overview The article discusses the upcoming Gradle 9 release based on an interview with Louis Jacomet at Devoxx France. It highlights performance, comprehensibility, support for modern Java and Kotlin versions, Configuration Cache improvements, plugin compatibility, and Isolated Projects. ### Source excerpt At Devoxx France, we sat down with Louis Jacomet, a tech lead at Gradle Inc. Louis leads the Gradle Build Tool support team and coordinates releases, so you can often see him active on GitHub issues and speaking at Gradle conferences. Let's dive into what Louis shares about the upcoming Gradle 9 release! A Busy Day at Devoxx FR Louis had a packed schedule on Friday at Devoxx FR, with 4 hours of talks lined up. He did a session with Hervé Boutemy from the Apache Maven community on navigating the labyrinth of dependency management, which was a 1-hour talk. He also had a separate discussion with his colleague Paul Merlin about the upcoming features in Gradle 9. Preparing for so many talks at once is no small feat. As Louis puts it: Thinking about what you want to say, organizing it, having cool demos, and making it interesting for the audience. Yeah, it's work. At the conference, Maven and Gradle folks worked together to share tips and best practices on dependency management in both systems. See the talk by Louis and Hervé Boutemy here (in French): Key Areas in Gradle 9 So what can we expect in Gradle 9? Louis outlined a few key areas they're focusing on for this next major version of Gradle: 🚀 Performance 💡 Comprehensibility 🐘 Support for modern Java and Kotlin versions Configuration Cache Improvements One major focus is continuing the work on the Configuration Cache, which was marked stable in Gradle 8.1. In Gradle 9.0, the Configuration Cache will be the preferred mode of execution, and turning it off will be deprecated. This means every build should use the Configuration Cache feature, speeding up the configuration phase and making builds faster overall. Gradle configuration is a significant part of the build, hence the Configuration Cache improvements. However, this necessitates considerable effort on internal Gradle plugins and accommodating use cases that aren't always compatible. This is particularly true for community plugins. The Gradle team will continue col ## Gradle's Evolution - A Conversation with Adam Murdoch DevFeed: [Gradle's Evolution - A Conversation with Adam Murdoch]() Original publisher: [Read original article]() Author: Laura Kassovic Published: 2024-06-12T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Automation](), [Dependency management](), [Deployment](), [Android](), [Kotlin]() Tags: [android](), [automation](), [build-tool](), [build-tools](), [dependency-management](), [evolution](), [gradle](), [kotlin]() ### AI overview An interview with Gradle CTO Adam Murdoch traces Gradle's origins, growth, and evolution as a build tool. It discusses Gradle's expanding role across dependency management, deployment, production, Kotlin, and Android, along with major product milestones from 2012 through 2018. ### Source excerpt We had a conversation with Adam Murdoch, the CTO of Gradle, about his journey from the very origins of Gradle. Adam offers insights into the latest features and discusses the future of build tools. The Genesis of Gradle Adam began his journey with Gradle around 2008 while seeking a robust alternative to the Ant-based build systems that he used at the time. He recalls, "I was looking for a replacement for our Ant-based build system, came across this new tool called Gradle, started using it, [and] started sending in patches for improvements." Hans Dockter, the founder of Gradle, recognized Adam's contributions and invited him to join as a maintainer. This collaboration marked the beginning of a transformative journey in build automation. "Here we are 15 years later," Adam remarks, reflecting on the vast changes since those early days. Recognizing a growing ecosystem Reflecting on the evolution of build tools over the years, Adam notes the dramatic expansion of the ecosystem. "When we started Gradle, there were no microservices [...] building your software meant compiling some classes, making adjustments, and then you were done." Today, the landscape is vastly different. Build tools now need to handle various tasks from deployment to production, which were not considered when Gradle first began. The introduction of languages like Kotlin and platforms like Android has further expanded Gradle's role in the developer community. 2012: Gradle Build Tool 1.0 introduces a faster, more accurate dependency resolution engine and expands plugin support. 2014: Gradle Build Tool 2.0 improves performance and memory efficiency, introduces new dependency management features, and enhances incremental build support. 2016: Gradle Build Tool 3.0 enables the Gradle Daemon by default and enhances IDE support with auto-completion and navigation with Kotlin DSL. 2016: Gradle, Inc. releases Gradle Enterprise as a commercial product to build software better and faster with Build Scan® and Build C ## Gradle partners with GitHub on supply chain security DevFeed: [Gradle partners with GitHub on supply chain security]() Original publisher: [Read original article]() Author: Gradle Build Tool Published: 2024-04-18T04:00:00Z Content type: news Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [GitHub](), [supply-chain-security](), [Dependency management](), [Security](), [Developer experience]() Tags: [dependabot](), [dependencies](), [dependency-management](), [github](), [github-action](), [gradle](), [integrity](), [security](), [supply-chain-security]() ### AI overview Gradle and GitHub announce a technical partnership focused initially on software supply chain security and developer experience. The first feature is a Gradle dependency submission GitHub Action that automatically sends project dependencies to GitHub's dependency graph, helping users understand dependencies and receive Dependabot alerts. ### Source excerpt Gradle is happy to announce a technical partnership with GitHub focusing on multiple areas, starting with supply chain security and developer experience. With this partnership, we establish a direct connection between organizations and plan to cooperate on integrations between GitHub and Gradle to promote best security practices among Gradle users. The first feature being released as a part of this partnership is the dependency submission GitHub Action for Gradle, which can be configured to automatically submit dependencies to GitHub's dependency graph, helping users better understand their application and receive Dependabot alerts. This partnership will improve the experience of many users within the shared Gradle and GitHub ecosystem. GitHub is the world's leading AI-powered developer platform to build, scale, and deliver secure software, home to more than 284 million public repositories. Gradle Build Tool is the default build system for Android application development, the most used JVM build system on GitHub, and among the most used build systems on the GitHub platform across public and private repositories. "Gradle is one of the most used build tools among GitHub users, and we're excited to continue to collaborate with them to improve supply chain security for the Gradle community. These updates to the Gradle Build Action will help millions of GitHub users improve the security of their apps by giving them better insights into their dependencies." - Jon Janego, Senior Product Manager at GitHub The problem with vulnerable dependencies Vulnerable project dependencies are a major risk for the software ecosystem. It's critical for developers to quickly detect potential vulnerabilities arising from both direct and transitive dependencies. It is a priority for many modern build systems, including Gradle, to help developers manage their dependencies and protect the supply chain and end users. Gradle Build Tool provides advanced security features like dependency verific ## Spotlight on SIG Architecture: Code Organization DevFeed: [Spotlight on SIG Architecture: Code Organization]() Original publisher: [Read original article]() Author: The Kubernetes Authors Published: 2024-04-11T00:00:00Z Content type: article Language: en Sources: [Kubernetes Contributors Blog]() Topics: [Code](), [Kubernetes](), [Go Language](), [Dependency management](), [GitHub]() Tags: [architecture](), [code](), [cycles](), [dependencies](), [dependency-management](), [github](), [go](), [interview](), [kubernetes](), [series](), [technical](), [vmware]() ### AI overview An interview in the SIG Architecture Spotlight series examines Kubernetes code organization. It discusses the scale of the Kubernetes Go codebase, dependency management, publishing Go modules, and using a monorepo with downstream repositories. ### Source excerpt This is the third interview of a SIG Architecture Spotlight series that will cover the different subprojects. We will cover SIG Architecture: Code Organization . In this SIG Architecture spotlight I talked with Madhav Jivrajani (VMware), a member of the Code Organization subproject. Introducing the Code Organization subproject Frederico (FSM): Hello Madhav, thank you for your availability. Could you start by telling us a bit about yourself, your role and how you got involved in Kubernetes? Madhav Jivrajani (MJ): Hello! My name is Madhav Jivrajani, I serve as a technical lead for SIG Contributor Experience and a GitHub Admin for the Kubernetes project. Apart from that I also contribute to SIG API Machinery and SIG Etcd, but more recently, I've been helping out with the work that is needed to help Kubernetes stay on supported versions of Go , and it is through this that I am involved with the Code Organization subproject of SIG Architecture. FSM: A project the size of Kubernetes must have unique challenges in terms of code organization - is this a fair assumption? If so, what would you pick as some of the main challenges that are specific to Kubernetes? MJ: That's a fair assumption! The first interesting challenge comes from the sheer size of the Kubernetes codebase. We have ≅2.2 million lines of Go code (which is steadily decreasing thanks to dims and other folks in this sub-project!), and a little over 240 dependencies that we rely on either directly or indirectly, which is why having a sub-project dedicated to helping out with dependency management is crucial: we need to know what dependencies we're pulling in, what versions these dependencies are at, and tooling to help make sure we are managing these dependencies across different parts of the codebase in a consistent manner. Another interesting challenge with Kubernetes is that we publish a lot of Go modules as part of the Kubernetes release cycles, one example of this is client-go .However, we as a project would ## Installing Python on a Mac with pyenv and pyenv-virtualenv DevFeed: [Installing Python on a Mac with pyenv and pyenv-virtualenv]() Original publisher: [Read original article]() Author: Raphaël Hoogvliets Published: 2024-02-07T09:27:30Z Content type: tutorial Language: en Sources: [Raphaël Hoogvliets]() Topics: [Python](), [Dependency management]() Tags: [dependency-management](), [install](), [mac](), [python]() ### AI overview This tutorial recommends using pyenv with pyenv-virtualenv to install and manage Python on a Mac. It explains how pyenv supports multiple Python versions, project-specific version pinning, user-local installations, and isolated per-project dependencies. ### Source excerpt Carefree and flexible Python use awaits you! ## Separation of Concerns in Cross-Compilation DevFeed: [Separation of Concerns in Cross-Compilation]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2024-01-30T00:00:00Z Content type: tutorial Language: en Sources: [Nixcademy Blog]() Topics: [Cross-Compilation](), [Nix](), [C++](), [Dependency management](), [Compiler](), [Dockerfile](), [static linking]() Tags: [c-plus-plus](), [compilation](), [compiler](), [cross-compilation](), [dependency-management](), [development](), [docker](), [static-linking]() ### AI overview This guide explains how Nix applies separation of concerns to cross-compilation in complex C++ projects. It discusses compiler selection, dependency management, external libraries, distribution, Docker-based workflows, and static linking. ### Source excerpt Master cross-compilation in complex C++ projects with Nix. Simplify dependency management, boost development speed, and reduce costs with this guide! ## Comparing the Dependency Size of AWS Java SDK v1 and v2 SQS Clients DevFeed: [Comparing the Dependency Size of AWS Java SDK v1 and v2 SQS Clients]() Original publisher: [Read original article]() Author: Doug Tangren Published: 2024-01-19T16:40:54Z Content type: article Language: en Sources: [Making Meetup - Medium]() Topics: [Java](), [Amazon Web Services](), [SDKs](), [Amazon Simple Queue Service (SQS)](), [Netty](), [Gradle](), [Architecture & Design]() Tags: [aws](), [dependencies](), [dependency-management](), [gradle](), [java](), [maintenance](), [sdk](), [sdks](), [security-vulnerabilities](), [sqs]() ### AI overview This article from Meetup compares the dependency size of AWS SDK for Java v1 and v2 using SQS client versions 1.12.637 and 2.23.3. It attributes the larger v2 footprint largely to bundled defaults and transitive dependencies, including Netty, and discusses the maintenance and security costs of dependencies. ### Source excerpt Photo by Nathan Dumlao on Unsplash At Meetup, two of our core engineering principles are to be cost conscious and use technologies that are proven to scale. On Meetup every time you click an attend button, schedule an event, create a group, start a conversation, decide join the local puppy group in your neighborhood, or any other activity your request is guaranteed to pass through multiple JVMs and within those, likely half a dozen AWS services along the way which themselves are often sitting in front of multiple JVMs. Both the JVM and AWS APIs are considered proven, rock-solid, and scalable technologies at Meetup. This is why we're heavily invested in Java and AWS for our core platform services as well as keeping both up to date. Like many companies, AWS included, we've completed the spiritual journey of migrating our largest primary platform codebase from Java 8 to 11, then to 17, and most recently to 21. The renaissance happening with the Java community has been wonderful and has unlocked a number of options for us, one being the subject of this post. Being a 20 year strong engineering focused company, we've accumulated a lot learnings in the area of understanding the cost of code dependencies. We've learned it's much easier to add than to remove dependencies and that the simplest solution to avoid the future burden of maintenance tax and security vulnerabilities attached to dependencies is simply not to invite them to the party in the first place so we're relatively conservative when evaluating new dependencies. We understand the long term tax and cost involved in doing so. When evaluating the new v2 AWS SDKs for Java, the first surprise we encountered was that it was nearing twice the size of that of the equivalent v1 SDK clients. While we started our V2 migration journey relatively long ago we recently revisited and this is still more or less the same case. We'll compare the AWS SDK SQS client versionsv1.12.637vs v2.23.3 respectively in this post. Here is an e ## Handling security vulnerabilities in Spring Boot DevFeed: [Handling security vulnerabilities in Spring Boot]() Original publisher: [Read original article]() Author: Brian Vermeer Published: 2023-11-29T06:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [Spring Boot](), [Vulnerabilities](), [Dependency management](), [Security](), [snyk-open-source]() Tags: [application-security](), [awareness](), [blog](), [dependencies](), [dependency-management](), [developer](), [devrel](), [gradle](), [java](), [open-source-security](), [sca](), [security](), [snyk-open-source](), [spring-boot](), [vulnerabilities]() ### AI overview This article explains how to identify and remediate open source security vulnerabilities in Spring Boot applications. It emphasizes dependency management, uses Snyk Open Source as a software composition analysis tool, and discusses updating vulnerable transitive dependencies, including updating the Spring Boot Webflux starter from 2.7.16 to 2.7.17. The supplied text ends while discussing Maven and Gradle configuration. ### Source excerpt In this blog, we'll demonstrate the best way to find and remediate open source vulnerabilities in Spring Boot. ## Tips and tricks for using Renovate DevFeed: [Tips and tricks for using Renovate]() Original publisher: [Read original article]() Author: Harsh Shandilya Published: 2023-01-17T19:32:18Z Content type: tutorial Language: en Sources: [Posts on Harsh Shandilya]() Topics: [renovate](), [configuration](), [Dependabot](), [ci](), [GitHub Actions](), [Regular expression](), [Hugo](), [JavaScript](), [Netlify]() Tags: [config](), [configuration](), [dependabot](), [dependencies](), [dependency-management](), [github](), [github-actions](), [hugo](), [netlify](), [regex](), [renovate](), [tips]() ### AI overview A practical guide to using Renovate for dependency management. It covers disabling updates for selected packages, grouping related updates, setting semver bounds, detecting dependencies in non-standard declarations with regular expressions, securing GitHub Actions with exact commit SHAs, and automatically merging compatible updates. ### Source excerpt Renovate is an extremely powerful tool for keeping your dependencies up-to-date, and its flexibility is often left unexplored. I'm hoping to change that ## Building a Semantically Correct Blockchain in Go: Genesis Blocks and Asset On-Ramping DevFeed: [Building a Semantically Correct Blockchain in Go: Genesis Blocks and Asset On-Ramping]() Original publisher: [Read original article]() Published: 2022-12-19T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Blockchain](), [Dependency management](), [Library]() Tags: [blockchain](), [blockchain-asset](), [blockchain-equity](), [dependency-management](), [ethereum](), [genesis](), [genesis-block](), [go](), [go-blockchain](), [standard-library](), [video]() ### AI overview This video explains how to build a semantically correct blockchain entirely with Go. It covers how a blockchain starts, the role of the genesis block, and how assets are introduced into the blockchain, while building on concepts from an earlier dependency-management example. ### Source excerpt Introduction In the first part of the series, Bill designed a dependency management system. The dependency manager needed to be distributed, transparent, cryptographically auditable and scalable. To meet these requirements, Bill borrowed concepts from blockchain. He did this to illustrate how the blockchain can be repurposed and used to accomplish the mundane task of dependency management. While doing so, Bill indirectly highlighted the problems a blockchain solves. In the next segment of the series, Bill will build a semantically correct blockchain. He plans to perform this task entirely with Go and he'lll re-use the ideas described in the previous segment to further facilitate your understanding of what a blockchain is. Early on Bill admits he is no economist, and for the sake of the series he will use a hypothetical pot of gold as the starting equity for his blockchain. Follow along and learn how assets are "on-ramped" into the blockchain. ## Ultimate Go: Advanced Engineering Episode 2 DevFeed: [Ultimate Go: Advanced Engineering Episode 2]() Original publisher: [Read original article]() Published: 2022-12-13T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Go Language](), [Dependency management](), [Blockchain](), [Algorithm](), [Command-line interface](), [Database]() Tags: [algorithm](), [blockchain](), [cli](), [database](), [dependency-management](), [go](), [go-blockchain](), [golang-blockchain](), [hash-algorithms](), [hash-collision](), [hashing](), [sha-256](), [sha256]() ### AI overview This video tutorial explains how dependency management in Go relates to reproducible builds, blockchain hashing, and trust in a centralized dependency database. It introduces hashes as distributed identifiers, explains collisions, and discusses the use of SHA-256 to reduce collision risk. ### Source excerpt Introduction In episode 1, Bill finished by describing the dependency management conundrum Go faced in its early days. Prior to the Go team providing the module system, developers were on their own to find a solution. Engineers in the Go community did propose different solutions, but there was no general consensus on which tool to use for dependency management. In this video, Bill will begin to architect a solution to the reproducible build problem. By doing so, you will learn how blockchain hashing works and then Bill will share how centralizing this dependency database will cause other problems. One of these problems is people eventually losing trust in the database because only one stakeholder, Bill, can make changes to it without a means for users to detect the change. He closes this segment with an important question, "how do we establish trust for this CLI's database?" ## Composer for the Rest of Us DevFeed: [Composer for the Rest of Us]() Original publisher: [Read original article]() Author: andrew@nystudio107.com (Andrew Welch) Published: 2022-08-14T20:04:00Z Content type: tutorial Language: en Sources: [nystudio107 | Articles on modern web development.]() Topics: [Composer](), [Dependency management](), [PHP](), [Command-line interface](), [JSON]() Tags: [cli](), [composer](), [dependencies](), [dependency-management](), [insights](), [install](), [json](), [learn](), [leverage](), [like](), [manage](), [php](), [php-based](), [projects]() ### AI overview A tutorial on Composer, the PHP dependency-management tool. It explains how Composer declares, installs, updates, and autoloads project dependencies, then introduces composer.json, composer.lock, Packagist, and useful Composer commands. ### Source excerpt Learn about how you can leverage Composer like a pro to manage & install your dependencies in PHP-based projects ## Practical Uses Of Blockchain Technology DevFeed: [Practical Uses Of Blockchain Technology]() Original publisher: [Read original article]() Published: 2022-06-06T00:00:00Z Content type: article Language: en Sources: [William Kennedy]() Topics: [Blockchain](), [blockchain technology](), [Dependency management](), [Database](), [Cryptography](), [Code]() Tags: [blockchain](), [blockchain-signature-verification](), [blockchain-technology](), [build-blockchain-from-scratch](), [cryptographically-auditable](), [cryptography](), [database](), [dependency-management](), [digital-wallet](), [distributed](), [ecdsa](), [ethereum](), [genesis-file](), [go-blockchain](), [golang-blockchain](), [verification]() ### AI overview The article explains practical uses of blockchain technology, focusing on a dependency-management verification system. The proposed system hashes code retrieved from a version-control system and compares it with a database record to detect changes. Cryptographic auditing and append-only records are presented as ways to make the database verifiable. ### Source excerpt Introduction A blockchain is an integrated solution of different computer science problems in the form of a single, append-only, publicly available, transparent, and cryptographically auditable database that runs in a distributed and decentralized environment. I've heard many times that blockchain is a technology looking for a problem to solve. I disagree with that assessment because the tech and computer science behind blockchain has practical uses in everyday engineering problems. One use of this technology that comes to mind is a dependency management verification system. [Next page]()