# Build tool Published articles for Build tool. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Three Gradle Talks from KotlinConf 2026 (and What to Steal from Each) DevFeed: [Three Gradle Talks from KotlinConf 2026 (and What to Steal from Each)]() Original publisher: [Read original article]() Author: Laura Kassovic Published: 2026-07-28T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Kotlin](), [Groovy](), [ide](), [Scripting](), [Refactoring]() Tags: [2026](), [best-practices](), [build](), [build-tool](), [conference](), [developer](), [dsl](), [event](), [gradle](), [groovy](), [ide](), [kotlin](), [kotlinconf](), [refactoring](), [script](), [scripting](), [talk](), [talks]() ### AI overview The article reviews three Gradle talks from KotlinConf 2026. It explains the progression from Groovy build scripts to the Kotlin DSL and early Declarative Gradle, emphasizing the problems each approach addresses. It also introduces Gradle best practices for organizing and optimizing builds. ### Source excerpt Every year I tell myself I'll watch every conference talk I missed. Every year I get through maybe three before a build breaks and I get pulled back into real life. KotlinConf is the one event where I actually follow through, partly because the talks are short and dense, and partly because a good chunk of my coworkers and friends are on stage. This year in Munich, three of them talked about Gradle: Paul Merlin on the history of our DSLs, Stefan Wolf on best practices, and Marcin Mycek on Declarative Gradle for Kotlin. I watched all three so you can decide which ones are worth your fifteen minutes. A Tale of the Gradle DSLs -- Paul Merlin Paul has been inside Gradle's DSL machinery for years, which makes him exactly the right person to tell this story and exactly the wrong person to pretend the early days were clean. The talk traces how build logic went from Groovy, to the Kotlin DSL, to Declarative Gradle. The useful part isn't the timeline. It's that each of those was solving a real problem the previous one couldn't. Groovy gave us a flexible, dynamic scripting language, which was great right up until you wanted your IDE to tell you what was valid. The Kotlin DSL brought static typing, real autocompletion, and refactoring that doesn't rely on hope. That's why the Kotlin DSL is now the default for new Gradle builds. Declarative Gradle is the next swing: describe what your build is rather than script how it runs. The honest through-line is that none of these fully replaces the last one. Kotlin DSL is where most people should be today. Groovy still runs an enormous amount of the world's build logic and isn't going anywhere fast. Declarative Gradle is early but points at where things are headed. Real talk: if your build scripts are still Groovy and still working, you don't have to panic-migrate this weekend. But if you're starting something new, reach for the Kotlin DSL and let the IDE carry some of the weight. 📺 Watch the talk 10 Gradle Best Practices Every Kotlin Deve ## Achieving Fast Inner Dev Loops with Gradle: Configuration Cache and Beyond DevFeed: [Achieving Fast Inner Dev Loops with Gradle: Configuration Cache and Beyond]() Original publisher: [Read original article]() Author: Alex Semin Published: 2026-05-20T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [code productivity](), [build performance](), [build times](), [Development]() Tags: [build](), [build-tool](), [compilation](), [context](), [developer-productivity](), [flow](), [gradle](), [incremental](), [kotlinconf](), [parallelism](), [productivity]() ### AI overview This article explains how Gradle is working to accelerate inner developer loops. It describes the shift from execution time to configuration time as the main build bottleneck in large codebases, while highlighting configuration cache, incremental builds, build cache, and parallelism as approaches to reduce waiting and preserve developer flow. ### Source excerpt How many engineers in your organization have to sit idle for 10 or more minutes just to rebuild the app locally after a small change? If you're an engineering leader, build engineer, or part of a developer productivity team, you're not alone in facing this challenge. Building complex software is inherently demanding, but the time your developers spend waiting has a profound impact beyond just the literal minutes lost. It fundamentally disrupts their psychological flow. "There are like these time scales of psychological flow, right? So if something takes longer than a minute, you already start planning for it... you suffer from context switch as well. If it's 1 second, that's where we want to be right in that seamless state of flow. And if it's less than one second, then you feel it's like magic... productive developers are happy developers." -- Rodrigo Oliveira When developers have to wait, their attention drifts, and the cost of context switching destroys their momentum. Our goal as enablers of developer productivity should be to eliminate this friction, bringing that feedback loop as close as possible to the "magical one second". In a recent presentation at KotlinConf 2025, Gradle engineers Rodrigo Oliveira and Alex Semin detailed how Gradle Build Tool is evolving to keep developers in that productive, happy "flow state". By tackling the most significant bottlenecks in modern software builds, Gradle is paving the way for incredibly fast inner developer loops. If you prefer to watch the presentation recording, you can find it here. The shifting bottleneck: From execution to configuration On every invocation, Gradle goes through three distinct phases: initialization, configuration, and execution. Historically, when we optimized Gradle builds, we focused almost exclusively on the execution phase. This is when the majority of work expected by a developer happens: production sources compilation, test execution, etc. For years, execution was the longest phase. We tackled thi ## Java Dependency and Classpath Problems in Gradle and Maven Builds DevFeed: [Java Dependency and Classpath Problems in Gradle and Maven Builds]() Original publisher: [Read original article]() Author: Tony Robalik Published: 2025-11-24T20:15:12Z Content type: opinion Language: en Sources: [DEV Community: Tony Robalik]() Topics: [Java](), [Gradle](), [Maven](), [Kotlin](), [Back end]() Tags: [analysis](), [build-tool](), [coding](), [community](), [compilers](), [dependencies](), [dependency](), [development](), [ecosystem](), [engineering](), [gradle](), [inclusive](), [java](), [jvm](), [kotlin](), [maven](), [software](), [software-supply-chain-attack]() ### AI overview This opinion article examines dependency and classpath problems in the Java ecosystem, including misleading metadata, fat JARs, split packages, reflection, protobuf usage, and compiler differences. It explains how classloader behavior can create conflicts and notes that classpath properties can also enable software supply-chain attacks. ### Source excerpt I am the author of the moderately popular (⭐ 2k) Dependency Analysis Gradle Plugin, a static analysis tool that helps Gradle build authors maintain a healthy dependency graph. I also maintain some of the largest Gradle repos on the planet: a Kotlin backend repo with over 2500 subprojects, and an Android repo with more than 7200 subprojects (both proprietary). I have... seen some shit. Note: I refer to both the cases above as being part of the "Java ecosystem," though both use Kotlin as the preferred language, and one runs on the JVM while the other runs on ART (the Android runtime) on mobile devices. I come to you with a simple proposition: I believe the Java ecosystem is cursed. Hear me out. We are cursed with... Lying metadata, overuse of "fat" jars with underuse of package relocation, split packages, undocumented usage of reflection to access upstream dependencies, usage of terms like "upstream" that have different meanings in different contexts, misuse of protobuffers, different compilers with different notions of their obligations vis-a-vis the Java class file format... Lying metadata This was already covered in-depth in This is why we can't have nice things: When POM files lie, but the summary is: sometimes dependencies have hand-written metadata, which is certainly A Choice given that build tools exist. I suppose it's harder to teach a build tool to lie. It's just a list, man Despite the bewildering complexity of dependency resolution engines in tools like Gradle and Maven, at the end of the day a classpath is just a list of class files (and jars that package class files). When your running program "sees" a class or interface for the first time, it has to load it. It does this with a ClassLoader. The classloader searches the classpath (just a list of class files!)1 and picks the first class file that matches the class it just encountered. Importantly, your classpath may have more than one class file for that class. Even well-behaved builds may have this problem, fo ## Tech predictions for 2025 DevFeed: [Tech predictions for 2025]() Original publisher: [Read original article]() Author: Mads Brodt Published: 2025-01-03T13:43:36Z Content type: opinion Language: en Sources: [Front-End Focus]() Topics: [Front end](), [Frameworks](), [React](), [Astro](), [Angular](), [Vite](), [Svelte](), [Vue.js](), [Artificial Intelligence](), [Job](), [Qwik]() Tags: [2025](), [adoption](), [ai](), [angular](), [astro](), [build-tool](), [community](), [components](), [developers](), [job](), [predictions](), [qwik](), [react](), [release](), [svelte](), [tailwind](), [tech](), [ui](), [vite](), [vue]() ### AI overview An opinion piece forecasting front-end development trends for 2025. It discusses the continued prominence of React-based production stacks, the potential standardization of React, NextJS, Tailwind, and ShadCN UI, the effects of framework competition and AI on developers, and expected growth for Astro and Vite/Rolldown. ### Source excerpt Happy New Year! ## Gradle brainteasers 2/2: relocatable input files DevFeed: [Gradle brainteasers 2/2: relocatable input files]() Original publisher: [Read original article]() Author: Martin Bonnin Published: 2024-07-17T08:41:15Z Content type: tutorial Language: en Sources: [Martin Bonnin's blog]() Topics: [Gradle](), [GraphQL](), [Caching](), [Kotlin](), [Compiler]() Tags: [api](), [apollo](), [build-tool](), [cache](), [compiler](), [gradle](), [gradle-plugin](), [graphql](), [kotlin](), [plugin]() ### AI overview This tutorial explains how the Apollo Gradle Plugin models GraphQL input files so generated Kotlin package names remain correct without breaking Gradle build cache relocation. It recommends using FileCollection and related APIs to preserve each file's relative path and other input information. ### Source excerpt This is a follow up to this other post about having fun with the Gradle APIs. In this post, I'm talking about how I spent a shameful amount of time understanding how Gradle handles input files. The problem The Apollo Gradle Plugin is generating Kotli... ## 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 ## Replacing a Kotlin HashMap with Generated Code for Screen-Team Lookups DevFeed: [Replacing a Kotlin HashMap with Generated Code for Screen-Team Lookups]() Original publisher: [Read original article]() Author: Pierre-Yves Ricau Published: 2024-02-15T03:59:18Z Content type: tutorial Language: en Sources: [Py's blog]() Topics: [Programming](), [Kotlin](), [Optimization](), [make](), [Code](), [modules]() Tags: [android](), [build-tool](), [code](), [internals](), [java](), [kotlin](), [kotlin-compiler](), [memory](), [modules](), [optimization](), [performance](), [programming]() ### AI overview The article explores replacing a Kotlin map of roughly 1,000 screen classes and owner teams with generated code. It estimates the map's retained size at about 120 KB and considers a hash-based, code-generated lookup to reduce that memory use. ### Source excerpt Today I was mob programming with Square's Mobile & Performance Reliability team and we toyed with an interesting idea. Our codebase has classes that represent screens a user can navigate to. These classes are defined in modules, and these modules hav... ## Garn: a Nix-, Deno-, and TypeScript-based build tool and environment manager DevFeed: [Garn: a Nix-, Deno-, and TypeScript-based build tool and environment manager]() Original publisher: [Read original article]() Published: 2023-11-02T00:00:00Z Content type: release Language: en Sources: [Garnix Blog]() Topics: [Tool](), [Deno](), [Nix](), [TypeScript]() Tags: [build-tool](), [environment](), [typescript]() ### AI overview Garn is announced as a build tool and environment manager based on Nix, Deno, and TypeScript. ### Source excerpt Announcing garn, a build tool and environment manager based on Nix, Deno and Typescript ## C++ with Nix in 2023, Part 1: Developer Shells DevFeed: [C++ with Nix in 2023, Part 1: Developer Shells]() Original publisher: [Read original article]() Author: Jacek Galowicz Published: 2023-10-31T00:00:00Z Content type: tutorial Language: en Sources: [Nixcademy Blog]() Topics: [Nix](), [C++](), [Development](), [toolchain]() Tags: [build-tool](), [c-plus-plus](), [compilers](), [dependency](), [development](), [environments](), [installation]() ### AI overview This tutorial introduces Nix for C++ development, focusing on creating consistent and portable developer shells. It explains how Nix can manage compilers, build tools, and dependency libraries without modifying the rest of the system, and begins with a small example project. ### Source excerpt Discover how Nix simplifies C++ dev with consistent, portable environments. Create dev shells, switch compilers, and update dependencies seamlessly. ## Improvements in the Build Configuration Input Tracking DevFeed: [Improvements in the Build Configuration Input Tracking]() Original publisher: [Read original article]() Author: Mikhail Lopatkin Published: 2023-09-01T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [build performance](), [Caching](), [configuration]() Tags: [build-performance](), [build-tool](), [cache-invalidation](), [caching](), [configuration](), [dependencies](), [environment-variables](), [files](), [gradle]() ### AI overview This article explains improvements in Gradle's build configuration input tracking. It describes how the configuration cache fingerprints build scripts, dependencies, environment values, files, filesystem information, and external-process output, then rechecks those inputs to determine whether cached configuration results can be reused safely. ### Source excerpt The configuration cache is a feature that significantly improves build performance by caching the result of the configuration phase and reusing it for subsequent builds. Using the configuration cache, the Gradle Build Tool can skip the configuration phase entirely when nothing that affects the build configuration, such as build scripts, has changed. In Gradle 8.1, the configuration cache became stable and recommended for adoption. Stability, in this case, means that the behavior is finalized, and all breaking changes follow the Gradle deprecation process. In general, if something works now, it will continue to work the same way--unless the behavior is buggy and may lead to incorrect builds. While some features are not yet implemented, most users can already benefit from the speed-ups brought by the configuration cache. Build configuration inputs When writing configuration-cache-compatible build logic or plugins, it is important to understand what Gradle considers build configuration inputs and how they affect cache invalidation. The concept is similar to task caching: Everything that contributes to the build logic execution is an input. The configuration phase is an action. The resulting task execution graph is the output. Examples of the build configuration inputs are: Build scripts and their dependencies (plugins and libraries). Environment variables and system properties read at configuration time. Files read by the build logic or plugins at configuration time. Information about the file system (existence of files, directory structure) obtained at configuration time. The output of external processes executed at configuration time. When build logic or a plugin reaches out to something "environmental" at configuration time, the obtained data becomes part of the configuration cache fingerprint. Next time the build runs, Gradle checks if the values of the inputs are still the same--it re-reads environment variables, system properties, files, and re-runs external proces ## Kotlin DSL is Now the Default for New Gradle Builds DevFeed: [Kotlin DSL is Now the Default for New Gradle Builds]() Original publisher: [Read original article]() Author: Paul Merlin Published: 2023-04-13T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Kotlin](), [IntelliJ IDEA](), [Android Studio](), [ide](), [Declarative programming](), [Functional programming](), [Refactoring]() Tags: [android-studio](), [build-tool](), [declarative](), [dependencies](), [functional-programming](), [gradle](), [ide](), [intellij-idea](), [kotlin](), [refactoring]() ### AI overview This article explains that Kotlin DSL is now the default for new Gradle builds, while Groovy DSL remains supported for existing projects and users who prefer it. It describes Kotlin DSL's static typing, concise syntax, functional programming support, declarative build language, and IDE assistance in IntelliJ IDEA and Android Studio, including auto-completion, documentation access, source navigation, and context-aware refactoring. It also highlights support for version catalogs and improvements to code analysis and auto-completion. ### Source excerpt Kotlin DSL for Gradle was introduced in version 3.0 of the Gradle Build Tool in August 2016 and released as 1.0 in Gradle 5.0. Since then, it's been growing in popularity and has greatly improved the authoring experience of many Gradle builds. Kotlin DSL is now the default choice for new Gradle builds. This means that when creating a new project with Gradle, including in IntelliJ IDEA (starting with 2023.1) and Android Studio (starting with Giraffe), Kotlin DSL is the default option. Support for Groovy DSL will continue for existing projects or those who prefer to use it. In this post, we will explore the benefits of Kotlin DSL and why it is becoming the recommended option for new Gradle builds. We will also discuss some of the improvements that are planned for the future to make Kotlin DSL even better. About Kotlin DSL Kotlin is a powerful language that offers many features that make it an excellent fit for creating a DSL. Its static type system, concise and expressive syntax, and support for functional programming constructs make it easy to create readable and composable DSLs. Kotlin DSL for Gradle takes advantage of the Kotlin language to enable full IDE assistance for build authoring in IntelliJ IDEA and Android Studio. This includes auto-completion, smart content assist, quick access to documentation, navigation to source, and context-aware refactoring. With Kotlin DSL, you can edit your build logic with the same editing experience you are used to when working with your production and test code. Gradle combines Kotlin language features with its capabilities to provide an elegant and extensible declarative build language that enables expressing any build clearly and understandably. Dynamically added elements of the build model, like project dependencies (when using version catalog) or subproject names in multi-project builds, benefit from static typing and IDE assistance. Gradle plugins extend Kotlin DSL by contributing extensions and tasks made available static ## Building Apache Flink with Maven: Resolving HTTP Repository Dependency Issues DevFeed: [Building Apache Flink with Maven: Resolving HTTP Repository Dependency Issues]() Original publisher: [Read original article]() Published: 2022-12-18T12:45:00Z Content type: tutorial Language: en Sources: [Gunnar Morling]() Topics: [Maven](), [apache-flink](), [Security]() Tags: [apache](), [apache-flink](), [build-tool](), [dependencies](), [security](), [stream-processing]() ### AI overview This article describes issues encountered while building Apache Flink from source with Maven 3.8.6. It explains how dependency-defined HTTP repositories can be blocked by Maven 3.8.1 and later, and discusses tracing the problematic dependency and overriding the repository URL in settings.xml. ### Source excerpt As part of my new job at Decodable, I am also planning to contribute to the Apache Flink project (as Decodable's fully-managed stream processing platform is based on Flink). Right now, I am in the process of familiarizing myself with the Flink code base, and as such I am of course building the project from source, too. ## Remote and Distributed Build Patterns DevFeed: [Remote and Distributed Build Patterns]() Original publisher: [Read original article]() Author: Kyle Moore Published: 2022-07-12T06:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [build performance](), [Caching](), [build times](), [ci](), [Optimization](), [Cloud]() Tags: [build](), [build-times](), [build-tool](), [cache](), [ci](), [cloud](), [distributed](), [gradle](), [incremental](), [optimization]() ### AI overview This Gradle post explains remote and distributed build patterns, clarifies their terminology, and describes how remote build caches reuse previous execution results to reduce local and CI build times. ### Source excerpt A frequently-requested feature for the Gradle Build Tool is the ability to perform remote or distributed builds. But what exactly does this mean? And what are the motivations behind the requests? This post will explore the difference between remote vs. distributed builds and their variations. As there is no industry-wide agreement on consistent terminology for these concepts, the goal of this post is to give an overview of these patterns and how they relate to each other. Except for two JVM-specific references, these observations are generally applicable to software projects using any language or ecosystem. But Why? These features are typically discussed in the context of shortening build times on local developer machines. Extended build turnaround times hinder productivity in both local and CI environments, but the local build experience has a disproportionate effect on developer sentiment. Terminology The terms "remote" and "distributed" builds are not always used consistently in the industry and are often used interchangeably. Below, we'll give each a distinct definition. Firstly, we'll also define the more fundamental "build cache" optimization. What is a Remote Build Cache? The first pattern that includes a remote component that we'll discuss is the build cache. Similar to incremental builds, the build cache avoids execution of CPU-intensive operations like compiling source files or executing tests. While an incremental build leaves the outputs of the most recent local operation in-place on disk, a build cache does this by storing and reusing the results of any previous execution of the operation - much like restoring files from a backup. More importantly, the cache can be local-only, or shared amongst engineers (remote build cache). The CI environment is typically configured to write to a shared cache in the cloud. Each engineer's machine then pulls results from the shared cache. This means that the same sources need only be built once on a CI host avoiding ex ## Migrating Your Project to Maven DevFeed: [Migrating Your Project to Maven]() Original publisher: [Read original article]() Author: Steve Hannah Published: 2021-04-14T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [Maven](), [migration](), [Java](), [Maven Central]() Tags: [build](), [build-tool](), [java](), [maven-central](), [migration](), [zip]() ### AI overview This tutorial explains how to migrate existing Codename One Ant application and library projects to Maven. It introduces the Codename One Migration tool, describes its Java 8 or later requirement and lack of dependencies beyond Java, and outlines how to download and open it. ### Source excerpt As you may know, we are moving to Maven for our build tool. As part of this transition, we are moving towards a single Maven project structure, and away from separate structures for each IDE. This will be easier to maintain, and will also make it easier to collaborate on projects with other developers who use a different IDE (or no IDE at all). ## A Demo of a Service-Worker-Based Build Tool for Ember DevFeed: [A Demo of a Service-Worker-Based Build Tool for Ember]() Original publisher: [Read original article]() Author: Edward Faulkner Published: 2021-03-30T23:01:57Z Content type: article Language: en Sources: [Edward Faulkner]() Topics: [Ember](), [Webpack](), [Tool]() Tags: [build-tool](), [demo](), [ember](), [talk](), [tools](), [webpack]() ### AI overview This post accompanies a talk from EmberConf 2021 and presents a demo of a service-worker-based build tool for Ember. It implements enough of the Embroider v2 specification to crawl addon metadata and combine public assets, but remains incomplete and demo-quality. ### Source excerpt This post serves as a permalink to accompany my talk from EmberConf 2021. Mho The demo of the service-worker-based build tool is available here with instructions to run both the prebuilt binary (currently compiled only for OSX, sorry!) as well as how to rebuild everything yourself. It' ## Announcing Vite 2.0 DevFeed: [Announcing Vite 2.0]() Original publisher: [Read original article]() Published: 2021-02-16T00:00:00Z Content type: article Language: en Sources: [Vite]() Topics: [Vite](), [Front end](), [Web Development](), [React]() Tags: [build-tool](), [framework](), [frontend](), [integration](), [release](), [vite](), [web-development]() ### AI overview Vite 2.0 is introduced as a fast, lean build tool for frontend web development, combining a pre-configured development server with a bundler. The release adds a framework-agnostic core, a new plugin format and API, and esbuild-powered dependency pre-bundling for faster handling of dependencies and CommonJS-to-ESM conversion. ### Source excerpt Announcing Vite 2.0 February 16, 2021 - Check out the Vite 3.0 announcement Today we are excited to announce the official release of Vite 2.0! Vite (French word for "fast", pronounced /vit/) is a new kind of build tool for frontend web development. Think a pre-configured dev server + bundler combo, but leaner and faster. It leverages browser's native ES modules support and tools written in compile-to-native languages like esbuild to deliver a snappy and modern development experience. To get a sense of how fast Vite is, check out this video comparison of booting up a React application on Repl.it using Vite vs. create-react-app (CRA). If you've never heard of Vite before and would love to learn more about it, check out the rationale behind the project. If you are interested in how Vite differs from other similar tools, check out the comparisons. What's New in 2.0 Since we decided to completely refactor the internals before 1.0 got out of RC, this is in fact the first stable release of Vite. That said, Vite 2.0 brings about many big improvements over its previous incarnation: Framework Agnostic Core The original idea of Vite started as a hacky prototype that serves Vue single-file components over native ESM. Vite 1 was a continuation of that idea with HMR implemented on top. Vite 2.0 takes what we learned along the way and is redesigned from scratch with a more robust internal architecture. It is now completely framework agnostic, and all framework-specific support is delegated to plugins. There are now official templates for Vue, React, Preact, Lit Element, and ongoing community efforts for Svelte integration. New Plugin Format and API Inspired by WMR, the new plugin system extends Rollup's plugin interface and is compatible with many Rollup plugins out of the box. Plugins can use Rollup-compatible hooks, with additional Vite-specific hooks and properties to adjust Vite-only behavior (e.g. differentiating dev vs. build or custom handling of HMR). The programma ## Introducing file system watching DevFeed: [Introducing file system watching]() Original publisher: [Read original article]() Author: Stefan Wolf Published: 2020-05-29T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [build performance](), [Filesystems](), [build times](), [Development](), [Linux](), [macOS](), [Windows]() Tags: [blog](), [build](), [build-tool](), [command-line](), [files](), [incremental](), [linux](), [logging](), [macos](), [windows]() ### AI overview This article introduces Gradle file system watching, a feature that improves incremental build performance by retaining file system information in memory between builds. It reduces disk I/O by receiving operating system notifications about changes and reusing cached information for unchanged locations. The feature supports recent versions of Linux, macOS, and Windows and became production-ready in Gradle 6.7. ### Source excerpt This is the first installment in a series of blog posts about incremental development-the part of the software development process where you make frequent small changes. We will be discussing upcoming Gradle build tool features that significantly improve feedback time around this use case. This blog post has been updated after the feature has become production-ready in Gradle 6.7. In Gradle 6.5, we have introduced an experimental feature called file system watching that significantly accelerates incremental builds. When enabled, it allows Gradle to keep what it has learned about the file system in memory between builds instead of polling the file system on each build. This significantly reduces the amount of disk I/O needed to determine what has changed since the previous build. Since Gradle 6.7 this feature is ready for production use. We are planning to enable the feature by default in a later release. How does it work? In order to determine whether Gradle needs to execute a task, it needs to check if any of its input and output files have changed since the last build. The daemon stores this information about the file system till the end of the current build in memory in what we call the virtual file system. Without file system watching, the daemon does not know what happens to the file system in-between builds, and therefore it must discard all the collected information about the file system at the end of each build. When file system watching is enabled, the daemon instructs the operating system to notify it about changes on disk. Since the daemon knows what changed since the previous build, it can re-use the information in the virtual file system for all the unchanged locations, avoiding unnecessary disk I/O. Gradle ships with the necessary integration for the recent versions of Linux, macOS, and Windows. Other operating systems are not supported. File system watching in action You can enable file system watching by passing the command line switch --watch-fs or ## Spring Dependencies in Gradle Can Be Tricky DevFeed: [Spring Dependencies in Gradle Can Be Tricky]() Original publisher: [Read original article]() Author: piotr-kubowicz Published: 2020-01-13T00:00:00Z Content type: tutorial Language: en Sources: [Backend Development on nexocode]() Topics: [Gradle](), [Dependency management](), [Spring Boot](), [Spring Framework]() Tags: [build-tool](), [dependencies](), [gradle](), [java](), [jvm](), [security](), [spring](), [spring-boot](), [spring-framework]() ### AI overview This article explains why managing Spring dependencies with Gradle can be difficult, especially when applications use multiple Spring projects and related libraries. It recommends importing a Spring-provided BOM instead of managing versions manually, describes the history and limitations of the Spring Dependency Management Plugin, and shows that an attempted Jackson Databind version override may leave the vulnerable version in use. ### Source excerpt Spring is the most popular Java web framework for many years and Gradle has an established position as a build tool. You might expect it's easy to find instructions on how to set up those two together -- yet the Internet is filled with advice that will get you into trouble. The official Spring documentation does not make the situation any better in this case. Using Spring in your applications typically means your classpath contains not only Spring Framework itself, but also other Spring projects like Spring Security plus Spring dependencies that are independent libraries. It may require lots of work to get versions of dependencies right, avoiding incompatible versions being used together. So a much better solution is -- not to manage all those versions manually and choose a set suggested by Spring. Technically speaking: importing a BOM (bill of materials). ## Introducing Gradle Module Metadata DevFeed: [Introducing Gradle Module Metadata]() Original publisher: [Read original article]() Author: Cédric Champeau Published: 2019-03-07T05:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Dependency management](), [Java](), [Software](), [Logging]() Tags: [api](), [binaries](), [build-tool](), [dependencies](), [dependency-management](), [gradle](), [java](), [logging]() ### AI overview The article introduces Gradle Module Metadata 1.0, released with Gradle 5.3, as a way to improve dependency management. It explains how richer metadata can represent variants such as platform-specific binaries, source packages, and alternative API implementations, allowing consumers and build tools to express and resolve more precise requirements. ### Source excerpt Gradle Module Metadata reaches 1.0 in Gradle 5.3 and here we explain why you should be as excited as we are! Gradle Module Metadata was created to solve many of the problems that have plagued dependency management for years, in particular, but not exclusively, in the Java ecosystem. It is especially important because POM files (or Ivy files) are simply not rich enough to describe the reality of software nowadays where you might need to distinguish between binaries for different platforms or choose one particular implementation of an API when more than one is available. We will describe more examples later in this post. Some issues may have workarounds, but where those workarounds are hacky ones or even error prone. For example, did you realize that these are problematic: using classifiers for different Java versions, exclusions to avoid a particular logger binding, or adding first level dependencies just because you need to override a particular version? Gradle Module Metadata 1.0 is an answer to those problems and the first step towards better dependency management throughout our industry. What does it allow in practice? Have you ever cursed when you had both guava-jdk5 and guava-jdk8 on the classpath, and your application only worked because of lucky ordering of entries? Have you ever faced the problem of having different SLF4J bindings and only noticed at runtime? That's because these libraries have different variants that can't be described properly by existing metadata formats. How is a build tool even supposed to understand the difference between a jdk8 JAR, a sources one, or even an all one? Gradle Module Metadata is designed to explain the difference in such a way that consumers can express more precise requirements. For example, a consumer can specifically ask for something they can use with JDK 8. And in the case of SLF4J, the build tool will recognize that the Log4J binding is mutually exclusive with the java.util.logging one. The whole idea is to support ## Java SE 9 - JPMS modules are not artifacts DevFeed: [Java SE 9 - JPMS modules are not artifacts]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2017-04-24T08:12:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [modules](), [Maven](), [Maven Central]() Tags: [bug](), [build-tool](), [java](), [java9](), [maven-central](), [modules]() ### AI overview This article explains that Java Platform Module System modules in Java SE 9 are distinct from build artifacts such as JAR files. Each project version can produce a different artifact while retaining the same module name. Build tools such as Maven select the artifact version, while JPMS assembles the runtime module graph and rejects duplicate packages on the module path. ### Source excerpt This is the next article in a series I'm writing to help make sense of the Java Platform Module System (JPMS) in Java SE 9. JPMS was developed as Project Jigsaw. Other articles in the series are Module basics and Module naming. Module != Artifact If you want to grasp what JPMS modules are all about, it turns out that it is critical to understand what they are not. In particular, they are not artifacts. Firstly, lets define an artifact. An artifact is a file produced when developing software. For a project on Maven Central, this includes jar files of bytecode, jar files of sources and jar files of Javadoc. We are interested primarily in the bytecode for this discussion. Secondly, lets assume that a project is going to have the same module name over time. This is just like package names - projects don't change package name with every release. Given this, what is the mapping between an artifact and a module? Versions Each version of a project will consist of a different artifact (jar file), perhaps released on Maven Central. Each version will have the same module name. But, we also know that the Java platform (JPMS) does not know about versions or version-selection. Therefore, when assembling a modulepath for Java SE 9, something else is going to have to choose the correct version of the module. This will typically be the build tool, eg. Maven. But while the classpath will tolerate having two versions of the artifact (typically with bad consequences at runtime), the JPMS modulepath will refuse to start if there two modules contain the same package, as would happen if two versions of the same module are found. Maven already manages versions of course, picking one version from a set of versions, where all with the same groupId:artifactId. With Java SE 9 we can say that Maven is picking one artifact from a set of artifacts to use in the runtime JPMS module graph. Artifacts JPMS runtime module org.joda : joda-convert : 1.2 Build tool must pick one of these artifacts for th ## My first time using boot over leiningen DevFeed: [My first time using boot over leiningen]() Original publisher: [Read original article]() Published: 2015-06-05T00:00:00Z Content type: article Language: en Sources: [Adam Bard]() Topics: [boot](), [ClojureScript](), [Front end](), [Tooling]() Tags: [boot](), [build-tool](), [clojure](), [front-end](), [javascript](), [project]() ### AI overview A first-person account of trying Boot instead of Leiningen for ClojureScript development. The article explains how Boot's task-based build scripts can integrate a Middleman static-site project and simplify development workflows. ### Source excerpt When boot first appeared in my usual rotation of clojure news, I must confess that I didn't really see what the fuss was about. It seemed like someone had taken leiningen and broken out all its parts into functions, which you could then use to get your dependencies, build your project, and so forth. Don't you see! Leiningen is just a build tool, but boot could be anything. It could even be a build tool! ## Add multiple resource folders to an Android App DevFeed: [Add multiple resource folders to an Android App]() Original publisher: [Read original article]() Published: 2015-03-03T00:00:00Z Content type: tutorial Language: en Sources: [Antonio Leiva]() Topics: [Android](), [Gradle](), [App](), [Mobile]() Tags: [android](), [app](), [build-tool](), [gradle](), [gradle-plugin](), [how-to](), [mobile]() ### AI overview This tutorial explains how to configure multiple Android resource folders in Gradle. It shows how to use source sets to organize resources into separate directories while retaining a common resource folder. ### Source excerpt Everything Android, Kotlin and other random topics