# Maven Apache Maven is a build tool for Java projects that uses a project object model to manage compilation, testing, and documentation. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## IntelliJ IDEA 2026.2.3 Is Out! DevFeed: [IntelliJ IDEA 2026.2.3 Is Out!]() Original publisher: [Read original article]() Author: Maria Kosukhina Published: 2026-09-16T10:53:53Z Content type: release Language: en Sources: [The JetBrains Blog]() Topics: [IntelliJ IDEA](), [2026.2](), [Release notes](), [releases](), [Maven](), [Markdown](), [plantuml](), [WSL2](), [Ubuntu]() Tags: [2026-2](), [intellij-idea](), [markdown](), [maven](), [plantuml](), [release-notes](), [ubuntu](), [wsl2]() ### AI overview JetBrains released IntelliJ IDEA 2026.2.3 with fixes and improvements affecting Maven project data, IDE freezes, Markdown preview scrolling, PlantUML support, and applications using WSL2 mirrored networking. ### Source excerpt We've just released IntelliJ IDEA 2026.2.3. You can update to this version from inside the IDE, using the Toolbox App, or using snaps if you are a Ubuntu user. You can also download it from our website. The latest update brings the following improvements: For a comprehensive overview of the fixes, see the release notes. [...] ## App Intents: One Java Declaration for Siri, Spotlight, and Shortcuts DevFeed: [App Intents: One Java Declaration for Siri, Spotlight, and Shortcuts]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-08-27T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [Java](), [App](), [Android](), [iOS](), [Maven]() Tags: [android](), [app](), [build](), [bytecode](), [ios](), [java](), [maven-plugin](), [native](), [shortcuts](), [spotlight]() ### AI overview Codename One App Intents use Java annotations to generate reflection-free handlers for Siri, Spotlight, Shortcuts, Android launcher shortcuts, and internal application commands. The article explains build-time validation, entity parameters, routing, and concurrent handler execution. ### Source excerpt Codename One App Intents generate reflection-free handlers for Siri, Spotlight, Shortcuts, Android launcher shortcuts, and an application command layer from Java annotations. ## The Third-Generation GUI Builder: One Workspace for Every Form DevFeed: [The Third-Generation GUI Builder: One Workspace for Every Form]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-08-14T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [GUI](), [Maven](), [CSS](), [Java]() Tags: [css](), [gui](), [java](), [projects](), [rewrite]() ### AI overview Codename One has rebuilt its GUI Builder for a third generation. The new project-oriented workspace preserves guided layout while integrating Maven project structure, forms, live CSS, protected Java regions, and switching between forms. ### Source excerpt Codename One's third-generation GUI Builder keeps the guided layout work from the previous editor and rebuilds the workflow around Maven projects, live CSS, protected Java regions, and fast switching between forms. ## Why Codename One Is Moving Beyond Maven Central DevFeed: [Why Codename One Is Moving Beyond Maven Central]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-08-04T00:00:00Z Content type: release Language: en Sources: [CodeName One]() Topics: [Maven Central](), [migration](), [Cloudflare](), [Maven](), [hosting](), [Open Source](), [releases]() Tags: [cloudflare](), [hosting](), [maven-central](), [migration](), [open-source](), [releases]() ### AI overview Codename One is moving from Maven Central to a repository operated on Cloudflare R2. The staged migration includes a smaller release payload, dual publishing during the transition, and a planned cutover; the August 28, 2026 update says new releases now go only to the Codename One repository. ### Source excerpt Codename One is starting a staged move from Maven Central to a free Cloudflare R2 repository, with dual publishing, a smaller release payload, and an explicit cutover plan. ## How to Automate Artifact Cleanup in Harness Artifact Registry Without Breaking Production DevFeed: [How to Automate Artifact Cleanup in Harness Artifact Registry Without Breaking Production]() Original publisher: [Read original article]() Author: Shibam Dhar Published: 2026-08-04T00:00:00Z Content type: tutorial Language: en Sources: [Harness Blog]() Topics: [container images](), [Docker](), [Maven](), [npm](), [Helm charts](), [Python](), [CI/CD](), [sdlc](), [Microservice]() Tags: [ci-cd](), [cleanup](), [container-images](), [cost](), [deployment](), [docker](), [helm](), [npm](), [python](), [sdlc]() ### AI overview This hands-on walkthrough explains how Harness Artifact Registry lifecycle rules can automate cleanup across Docker, npm, Maven, Python, and Helm repositories while reducing the risk of deleting artifacts still used in production. It describes dry-run previews, governance tiers, recovery, and the limits of age-, count-, and tag-based rules. ### Source excerpt A hands-on walkthrough of Lifecycle Rules across Docker, npm, Maven, Python, and Helm. Includes dry-run preview, three-tier governance, and one-click recovery. | Blog ## AppFunctions, revisited DevFeed: [AppFunctions, revisited]() Original publisher: [Read original article]() Author: Thomas Künneth Published: 2026-07-25T11:36:27Z Content type: tutorial Language: en Sources: [Thomas Künneth]() Topics: [Jetpack](), [Android](), [Library](), [implementation](), [Maven]() Tags: [ai](), [android](), [androiddev](), [article](), [code](), [coding](), [community](), [development](), [engineering](), [implementation](), [inclusive](), [jetpack](), [library](), [maven](), [programming](), [software](), [update]() ### AI overview This tutorial revisits Android Jetpack AppFunctions after alpha10 stopped publishing appfunctions-service. It explains the new service entry-point model, generated subclasses and XML, manual service declaration, the removal of AppFunctionContext, and a correction about using installed-app display names instead of package names. ### Source excerpt In Agentic interaction using AppFunctions I showed how Be nice publishes createAppPair for agents, using Jetpack appfunctions 1.0.0-alpha08. That setup leaned on a library-merged PlatformAppFunctionService, an AppFunctionContext parameter, and aggregate XML named app_functions.xml / app_functions_v2.xml. When I bumped toward what Android Studio was suggesting as of mid July, Sync failed: Could not find androidx.appfunctions:appfunctions-service:1.0.0-alpha10. On 1 July 2026, alpha10 stopped publishing appfunctions-service (Maven still lists it through alpha09). The Add the AppFunctions API guide now expects you to host an @AppFunctionServiceEntryPoint AppFunctionService. Spoiler: that is the real change. The rest of this post is how that landed in Be nice, plus an important update to the earlier article that is easy to miss if you only chase compile errors. Correction first In the earlier post I wrote that agents would pass package names for app1 and app2. That was wrong for Be nice. The implementation matches display names, case-insensitively, against installed apps. Package names are a convenient engineer habit; they are a poor agent habit when the user said "Clock" and "Contacts". KDoc and app-level metadata have to say what the code accepts -- agents lean on that text harder than on your mental model of the APK. What changed in the model Before alpha10 you annotated a helper class and let the service AAR merge a stock entry point into the manifest. Starting with alpha10: @AppFunction lives in androidx.appfunctions (not androidx.appfunctions.service) It is only legal on methods of an abstract AppFunctionService marked @AppFunctionServiceEntryPoint KSP generates the concrete subclass named in serviceName and the XML named in appFunctionXmlFileName You declare that generated service yourself; nothing merges a stock one anymore There is no AppFunctionContext parameter; the service is a Context Drop appfunctions:aggregateAppFunctions. Grepping for empty app_functions. ## Versioned Builds Are Back, With Master Builds For Fast Verification DevFeed: [Versioned Builds Are Back, With Master Builds For Fast Verification]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-07-07T00:00:00Z Content type: release Language: en Sources: [CodeName One]() Topics: [releases](), [Development](), [Maven](), [Maven Central](), [Framework]() Tags: [enterprise](), [master](), [production](), [speed](), [verification](), [versioning]() ### AI overview Codename One reintroduces versioned cloud builds, allowing developers to pin builds to a specific published release or build against the current development head. The article explains use cases including production stabilization, regression diagnosis, and reproducing older customer environments, while noting that master builds are intended for verification rather than production shipping and that older versions are limited by account level because of support costs. ### Source excerpt Versioned builds return with a Maven-era model: pin a cloud build to a release, or build against master to verify the current development head. ## The Codename One Game Builder: Draw The Level, Code The Rules DevFeed: [The Codename One Game Builder: Draw The Level, Code The Rules]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-06-23T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [Code](), [3D](), [API](), [Java](), [JSON](), [Maven]() Tags: [3d](), [api](), [code](), [data](), [gaming](), [java](), [json](), [project](), [tutorial]() ### AI overview This orientation introduces the Codename One Game Builder, a visual level editor that saves plain-data .game files for runtime loading. It covers the editor's panels, Java 17 and Maven requirements, and its support for 2D, board, and 3D game modes. ### Source excerpt A visual level editor for the Codename One gaming API that saves a plain-data .game file the runtime plays, across 2D, isometric board, and 3D modes, plus a streaming engine for large open worlds. ## A2A in Java: hands on Embabel DevFeed: [A2A in Java: hands on Embabel]() Original publisher: [Read original article]() Author: Aneshka Goyal Published: 2026-06-21T07:01:03Z Content type: tutorial Language: en Sources: [Amex GBT Technology]() Topics: [Embabel](), [A2A protocol](), [Java](), [MCP](), [Spring AI](), [Maven](), [bedrock](), [Large Language Model]() Tags: [a2a](), [agent](), [ai](), [embabel](), [java](), [maven](), [mcp-server](), [software-engineering](), [spring-ai]() ### AI overview A hands-on tutorial for building a Java agent with Embabel. It demonstrates LLM-based story generation and review, Amazon Bedrock integration, a local Spring AI MCP server for word counts, Maven dependency management, and A2A-compliant endpoints. ### Source excerpt Part 2: Hands on with Embabel! In Part 1, we discussed how Embabel works internally. In Part 2, we'll now try to get an application started that has an LLM interaction, talks to local MCP server (for tools), and helps us achieve a goal. This time, we'll also make sure we use A2A protocol for our agent (something Embabel makes easier to do allowing us to focus on core business logic and offloading boilerplate code to Embabel). We'll use the project creator to create a skeleton project for us with some Embabel dependencies and code. uvx --from git+https://github.com/embabel/project-creator.git project-creator Please note we can use Java or Kotlin as our preferred language, I would be leveraging Java. This is a simple story teller agent who writes a story and gets it reviewed (both story generation and review comes from LLM). We'd be using Bedrock for connection to our LLM model. For fetching the word count for a topic, it uses an MCP server which is a Spring AI MCP server running locally. Dependency management is handled using Maven, and the POM file looks like this: 4.0.0 org.springframework.boot spring-boot-starter-parent 3.5.9 com.example.demo-city-agent Demo-city-agent 0.1.0-SNAPSHOT jar My first agent Generated agent project 21 0.3.1 com.embabel.agent ) Original publisher: [Read original article]() Author: Brian Vermeer Published: 2026-06-02T00:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [prompt injection](), [agentic-coding](), [AI-assisted coding](), [Open Source](), [Command-line interface](), [Maven](), [CI/CD](), [payload](), [Claude Code](), [cursor](), [GitHub Copilot]() Tags: [agentic-coding](), [agents](), [ai](), [ai-agents](), [ai-coding](), [article](), [awareness](), [ci-cd](), [claude-code](), [code](), [copilot](), [cursor](), [developer](), [devops](), [github](), [interest](), [java](), [open-source](), [open-source-security](), [payload](), [prompt-injection](), [sandbox](), [scm](), [security](), [security-labs](), [snyk-code](), [snyk-open-source](), [snyk-security-intel](), [supply-chain](), [supply-chain-security](), [testing](), [tools](), [vulnerability-insights]() ### AI overview The article examines jqwik 1.10.0, whose maintainer embedded a prompt injection in test output aimed at AI coding agents. ANSI terminal escape codes concealed the instruction from humans while leaving it visible to tools processing raw logs, creating a supply-chain risk for CI/CD pipelines and agentic coding workflows. ### Source excerpt jqwik 1.10.0 added a hidden prompt injection aimed at AI coding agents, using terminal escape codes to conceal destructive instructions from humans while leaving them readable to logs and tools. ## What is an Agentic Application? DevFeed: [What is an Agentic Application?]() Original publisher: [Read original article]() Author: Aneshka Goyal Published: 2026-05-06T04:01:01Z Content type: tutorial Language: en Sources: [Amex GBT Technology]() Topics: [Spring AI](), [Artificial Intelligence](), [Model Context Protocol](), [Amazon Bedrock](), [Spring Boot](), [Java](), [Maven](), [Large Language Model](), [Streaming]() Tags: [agentic](), [agentic-ai](), [ai](), [aws](), [developer](), [java](), [llm](), [maven](), [mcp](), [mcp-server](), [software-engineering](), [spring-ai](), [streaming]() ### AI overview A hands-on tutorial for building an agentic application with Spring AI. It demonstrates connecting an application to AWS Bedrock, exposing weather and latitude-longitude tools through a stateless MCP server over HTTP streaming, and combining MCP clients, memory, tools, and a system prompt. ### Source excerpt Part 2: Using spring AI to build a simple agentic application In Part 1 we discussed about core capabilities of Spring AI that helps it position itself as a strong framework to build Agentic applications. Taking things forward from there, let's now build something to bring things into action!! Scenario We want to build an application that connects with AWS bedrock for LLM integration. Has set of tools exposed from an MCP server running on HTTP streaming protocol in STATELESS mode(MCP is also built using Spring AI). For memory we use chat memory with inbuilt InMemory repository and MessageWindowChatMemory. This application has the ability to provide weather info, some lat long info for a particular city. MCP Server Setup Maven pom for dependency management 4.0.0 org.springframework.boot spring-boot-starter-parent 3.5.6 com.example mcp-server-demo 0.0.1-SNAPSHOT mcp-server-demo Demo project for Spring Boot 17 org.springframework.boot spring-boot-starter-web org.springframework.ai spring-ai-starter-mcp-server-webmvc 1.1.2 org.springframework.boot sprin ## Stream APIs, Swift Package Manager, Tutorial Trail Refresh, and the UWP Transition DevFeed: [Stream APIs, Swift Package Manager, Tutorial Trail Refresh, and the UWP Transition]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-03-20T00:00:00Z Content type: release Language: en Sources: [CodeName One]() Topics: [Java](), [iOS](), [Universal Windows Platform](), [Maven](), [Package manager]() Tags: [dependencies](), [ios](), [java](), [maven-plugin](), [swift-package](), [swift-package-manager](), [update]() ### AI overview Codename One adds built-in support for Java Stream APIs and Swift Package Manager integration for iOS dependencies, refreshes its written tutorial trail, and removes the UWP target from the Maven plugin in version 7.0.229. ### Source excerpt Codename One now includes built-in java.util.stream support, adds Swift Package Manager support for iOS dependencies, refreshes the written tutorial trail, and removes the UWP target from the Maven plugin in 7.0.229. ## \[Math\] Intervals: Apache Maven version numbers DevFeed: [\[Math\] Intervals: Apache Maven version numbers]() Original publisher: [Read original article]() Published: 2025-12-18T23:00:00Z Content type: article Language: en Sources: [Dennis Yurichev]() Topics: [Maven](), [math]() Tags: [apache](), [math](), [numbers]() ### AI overview This article explains how Apache Maven version ranges use mathematical interval notation, including fixed versions, half-open intervals, half-closed intervals, and omitted infinity signs. ### Source excerpt [Math] Intervals: Apache Maven version numbers ## Strengthening your Software Supply Chain DevFeed: [Strengthening your Software Supply Chain]() Original publisher: [Read original article]() Author: Andres Almiray Published: 2025-12-12T03:03:02Z Content type: article Language: en Sources: [Java Advent Calendar]() Topics: [supply-chain-security](), [reproducible builds](), [Java](), [Software](), [Maven]() Tags: [2025](), [build-tools](), [dependencies](), [devops](), [integrity](), [java](), [reproducible-builds](), [security](), [software-supply-chain](), [supply-chain]() ### AI overview This article explains how to strengthen the Java software supply chain beyond relying on build tools alone. It discusses SLSA security controls, attacks such as Log4Shell and the XZ backdoor, reproducible artifacts, and support from JReleaser for applying these practices. ### Source excerpt According to Wikipedia, a software supply chain is the components, libraries, tools, and processes used to develop, build, and publish a software artifact. The Java space provides thousands upon thousands of libraries that may be consumed as dependencies for building projects. Many of these libraries rely on Apache Maven as their build tool of choice, [...] The post Strengthening your Software Supply Chain appeared first on JVM Advent. ## 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 ## How Chainguard Libraries for Java Secures Dependencies at Maven Central Scale DevFeed: [How Chainguard Libraries for Java Secures Dependencies at Maven Central Scale]() Original publisher: [Read original article]() Published: 2025-06-25T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard libraries](), [Java](), [Reverse Dependencies](), [Maven](), [Open Source]() Tags: [central](), [chainguard-libraries](), [chainguard-libraries-for-java](), [dependencies](), [graph](), [java](), [java-libraries](), [java-packages](), [libraries](), [maven-central](), [open-source](), [supply-chain]() ### AI overview This article explains how Chainguard is building Chainguard Libraries for Java to secure open-source JVM dependencies from Maven Central. It describes the repository's scale and the initial selection strategy, which uses dependency-graph data to identify popular libraries and prioritizes newer projects. ### Source excerpt Chainguard Libraries for Java is Chainguard's repository of malware-resistant Java dependencies. Learn how we are building and maintaining over 50,000 projects. ## New Maven Central signing key and snapshot location DevFeed: [New Maven Central signing key and snapshot location]() Original publisher: [Read original article]() Author: Jake Wharton Published: 2025-06-13T00:00:00Z Content type: release Language: en Sources: [Cash App Code Blog]() Topics: [Maven Central](), [Maven](), [Publishing](), [Open Source]() Tags: [end-of-life](), [maven-central](), [open-source-artifacts](), [public-key](), [release](), [server-android](), [signing](), [snapshot](), [snapshots](), [verification]() ### AI overview Cash App migrated its open source artifact publishing to Sonatype's new platform after OSSRH reached end of life. The change introduces a company-wide GPG signing key and moves snapshot builds to the Central Portal Snapshot repository. ### Source excerpt In response to Sonatype announcing the end-of-life for OSSRH, we have migrated to their new publishing platform for our open source artifacts. This is otherwise a transparent change for those who consume these artifacts from Maven Central, but there are two related changes which might affect your builds. ## How to use a project-specific Maven repository when dependency downloads fail DevFeed: [How to use a project-specific Maven repository when dependency downloads fail]() Original publisher: [Read original article]() Author: Marco Gomiero Published: 2025-01-05T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Marco Gomiero]() Topics: [Maven](), [ci](), [Gradle]() Tags: [binaries](), [build](), [ci](), [dependencies](), [dependency](), [gradle](), [incident](), [maven]() ### AI overview This tutorial explains how to keep a project building when a Maven repository is unavailable or a dependency can no longer be downloaded. It shows how to create a project-specific local Maven repository, recover the dependency binary from the Gradle cache when available, and configure Gradle to use the local repository for that library. ### Source excerpt As developers, we've all encountered build failures in CI (or on our local machines) due to Maven repository issues preventing dependency downloads. > Could not download foo-lib-1.0.aar (org.acme.foo:foo-lib:1.0) > Could not get resource 'https://mavenrepo.com/org/acme/foo/foo-lib/1.0/foo-lib-1.0.aar'. > Could not GET 'https://mavenrepo.com/org/acme/foo/foo-lib/1.0/foo-lib-1.0.aar'. Received status code 403 from server: There could be many reasons for this: the Maven repository is currently down or is having an incident, the repository has been shut down (hello, JCenter), and the dependency is old and not republished elsewhere. ## Introducing the Keycloak Test Framework DevFeed: [Introducing the Keycloak Test Framework]() Original publisher: [Read original article]() Author: Lukas Hanusovsky Published: 2024-11-14T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Testing](), [Framework](), [Maven](), [OAuth](), [browsers](), [Chrome](), [Firefox](), [SDK]() Tags: [browsers](), [chrome](), [firefox](), [framework](), [guide](), [idm](), [kerberos](), [keycloak](), [ldap](), [maven](), [oauth](), [openid-connect](), [saml](), [sdk](), [sso](), [test](), [testing]() ### AI overview Keycloak introduces a new test framework designed to replace its current Arquillian-based test suite. The JUnit 5 extension supports custom injection, server and database lifecycles, clients and users, OAuth, UI testing, WebDriver integration, and multiple browsers. The framework is available in the main branch and nightly builds, with migration from the old testsuite beginning. ### Source excerpt How It All Started The idea to replace the current test suite has been on the table for multiple years. Initially, it was meant to be only a refactoring of the current approach on how to write tests, but after a few internal discussions and refactor updates it turned out a new test suite, based on a new framework would be a better solution. It would be good to mention a few drawbacks, that stand out when working with the current test suite. First of all, is the complexity of various configurations and additions made on top of the Arquillian framework. These changes make the test suite powerful, but the cons is that without proper documentation for beginners is almost unreadable. The second thing has the same importance, the Arquillian framework is not fully supported anymore. Other things to mention are a complicated execution system, where you want to specify what exactly should be tested, then abstract classes with shared configurations and missing the option to add a custom extension. Brighter Future? The Keycloak team began an effort to design a new test framework in May 2024. It started with a prototype to verify if our ideas were feasible. The prototype is a JUnit5 Extension based on the JUnit5 testing framework, specifically to implement JUnit5 callback classes which extend the default test lifecycle functionality and provide custom inject annotations, like @KeycloakIntegrationTest, @InjectWebDriver or @InjectRealm. After a successful test round, we've continued with a proof of concept extending features list to support multiple server modes, different databases and WebDrivers, clients and users setup, SmallRye configuration support, OAuthClient based on Nimbus SDK (this feature is a preview only) etc. The full list of currently implemented features is: Maven BOM Core module Server lifecycle Database lifecycle Admin client injection Realm, User, Client lifecycle and injection Event and Admin event listener and injection OAuth client injection UI module WebDri ## Keycloak Client Libraries 26.0.0 released DevFeed: [Keycloak Client Libraries 26.0.0 released]() Original publisher: [Read original article]() Author: Keycloak Team Published: 2024-10-04T00:00:00Z Content type: release Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [client](), [Maven]() Tags: [client](), [compatibility](), [idm](), [java](), [kerberos](), [keycloak](), [keycloak-client-libraries-release](), [ldap](), [maven](), [migration-guide](), [openid-connect](), [release](), [saml](), [sso](), [version]() ### AI overview Keycloak Client Libraries 26.0.0 introduces an independent release cycle for selected client libraries. The release also supports testing client libraries with the same server version and a few previous major server versions. ### Source excerpt Highlights Dedicated release cycle for the client libraries From this release, some of the Keycloak client libraries will have release cycle independent of the Keycloak server release cycle. The 26.0.0 release may be the last one when the client libraries are released together with the Keycloak server. But from now on, the client libraries may be released at a different time than the Keycloak server. The client libraries are these artifacts: Java admin client - Maven artifact org.keycloak:keycloak-admin-client Java authorization client - Maven artifact org.keycloak:keycloak-authz-client Java policy enforcer - Maven artifact org.keycloak:keycloak-policy-enforcer It is possible that in the future, some more libraries will be included. Compatibility of the client libraries with the server Beginning with this release, we are testing and supporting client libraries with the same server version and a few previous major server versions. Upgrading Before upgrading refer to the migration guide for a complete list of changes. ## Impact of final JCenter shutdown on Gradle Plugin Portal DevFeed: [Impact of final JCenter shutdown on Gradle Plugin Portal]() Original publisher: [Read original article]() Author: Louis Jacomet Published: 2024-07-05T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Maven](), [Package manager](), [configuration]() Tags: [analysis](), [blog-post](), [build](), [dependencies](), [gradle](), [jfrog](), [maven-central](), [proxy]() ### AI overview The article analyzes the impact of JCenter becoming a permanent redirect to Maven Central on the Gradle Plugin Portal and Gradle builds. It explains the portal's move from acting as a JCenter proxy to a Maven Central proxy and identifies plugin and transitive-dependency resolution failures that users may encounter. ### Source excerpt ℹ Update on July 15, 2024 We have found errors causing false positive in failed plugin resolution. 4 plugins have been removed from the list, resulting in 9 removed dependencies. We also added 105 plugins that depend on one or more affected plugins. These will fail to resolve transitively. Not taking exclude into account caused the first change, the second one came from not taking plugin dependencies into account. Now that JFrog has confirmed that JCenter will become a permanent redirect to Maven Central, we felt that it was important for the Gradle Plugin Portal users to understand the impact of that decision on the portal and their builds. This post follows our report after JCenter redirected to Maven Central for a day. Users still directly using JCenter should also refer to our original blog post about the changes in JCenter and their impact on Gradle builds in general. Upcoming Plugin Portal changes JCenter will become a permanent redirect to Maven Central. As a consequence, the Gradle Plugin Portal will no longer act as a JCenter proxy and will instead become a Maven Central proxy. The Gradle Plugin Portal will continue to return redirects (303 See Other) for artifact queries it cannot serve. Starting July 15, 2024, these redirects will be towards Maven Central instead of JCenter. This change might impact existing Gradle builds: Build using plugins with dependencies that are exclusively available on JCenter will fail to resolve. Builds configured to use the Gradle Plugin Portal as a regular artifact repository (which is not recommended) may be impacted. For more information, refer to our original blog post. We aim to document the potential impact on Gradle plugins provided by the Plugin Portal. Read our analysis below to learn how to minimize the impact on your builds. Impact analysis We have performed two major analyses: For all the plugins known to the Gradle Plugin Portal, determine which ones would fail to resolve if their transitive dependencies are resol ## Building minimal and low CVE images for Java DevFeed: [Building minimal and low CVE images for Java]() Original publisher: [Read original article]() Published: 2024-06-11T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard images](), [Java](), [Security](), [Dockerfile](), [Maven](), [grype](), [Spring Boot](), [Docker](), [Docker Hub]() Tags: [chainguard](), [chainguard-images](), [cves](), [docker](), [docker-hub](), [grype](), [java](), [java-migration](), [security](), [spring-boot](), [tooling]() ### AI overview This article demonstrates how to build smaller, lower-CVE container images for Java applications with Chainguard Images. It compares a Maven-based Docker image with a Chainguard equivalent, then uses a multi-stage build to remove build tooling and source code from the production image. ### Source excerpt Build secure, minimal Java images with fewer CVEs. Learn how Chainguard Images helps you optimize security and performance for your Java applications. ## Nonsensical Maven is still a Gradle problem DevFeed: [Nonsensical Maven is still a Gradle problem]() Original publisher: [Read original article]() Published: 2024-03-28T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [Maven](), [Gradle]() Tags: [build-system](), [dependencies](), [dependency](), [jvm]() ### AI overview The article argues that Maven's default dependency resolution strategy is problematic for libraries built with Gradle. It explains dependency graphs and contrasts Gradle's default preference for newer versions with Maven's "nearest definition" rule, where declaration order can cause an older transitive dependency to win. ### Source excerpt There was a time when I used Maven heavily, but today all the libraries I work on build with Gradle. Even though I'm publishing with Gradle, consumers can use Gradle, Maven, Bazel, jars in libs/ (but please don't), or anything else. That's a huge JVM ecosystem win! In general, I don't have to think about what build system someone is using. I'm not here to debate subjective pros and cons of one versus any other. There is one notable exception, however. Maven's dependency resolution strategy is objectively bonkers. And if we want to support Maven consumers, we need to think about it. If you already are familiar with the concept of dependency resolution, you can skip to the nonsense. Dependency resolution primer Chances are your build system of choice (or a separate dependency resolver tool) gives you a declarative way to describe your dependencies. At build time, those declarations are resolved to .jars which can be put on the compiler classpath. Sometimes we call this a dependency tree, but it's actually a dependency graph, as separate nodes can converge back to something common to both. Project (build.gradle) ├── A │ └── B │ └── C v1.0 └── D └── C v1.0 If library B and library D agree on the version of library C, then that is the .jar version which is used. If they disagree on versions, some policy needs to decide the appropriate single version to use. Pop quiz: If library B wants version 1.1 of library C, and library D wants version 1.0 of library C, which single version of C should we use? Project (build.gradle) ├── A │ └── B │ └── C v1.1 └── D └── C v1.0 This is not a trick question. Hopefully the answer feels obvious: you use the newer version, 1.1. That version is probably compatible with 1.0, so it's safe for both library B and library D to use. We can't know for sure, to be clear, but it's a safe choice. This behavior is the default in many dependency resolvers, including the one inside Gradle. The nonsense When building with Maven, given two dependencies who ## Krampus delivers an end-of-year Struts vulnerability DevFeed: [Krampus delivers an end-of-year Struts vulnerability]() Original publisher: [Read original article]() Author: Micah Silverman Published: 2024-01-02T06:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [vulnerability](), [Cybersecurity](), [Exploit](), [Library](), [Java](), [Maven](), [GitHub]() Tags: [acquisition](), [apache](), [application-security](), [blog](), [breach](), [code](), [code-security](), [cve](), [cybersecurity](), [developer](), [devrel](), [exploit](), [github](), [how-to](), [java](), [open-source-security](), [security](), [snyk](), [snyk-cloud](), [snyk-open-source](), [update](), [upgrade](), [vulnerability]() ### AI overview This article explains CVE-2023-50164, a critical path traversal vulnerability in Apache Struts. It describes the risk of remote code execution, demonstrates a proof-of-concept exploit, and recommends upgrading Struts to 2.5.33 or 6.3.0.2 or later. ### Source excerpt CVE-2023-50164 is a critical vulnerability in the Apache Struts library. Learn how to find and fix by upgrading your package and using Snyk to discover and remediate. [Next page]()