User blog: Tamas on Maveniverse

DOMTrip

Thu, 05 Feb 2026 15:07:53 +0100

Round-trip editing is a programmatic changing/editing of an existing XML document, like for example a Maven POM is, while preserving all the formatting, comments and all properties of the original document.

Programmatic “editing” of POMs and other Maven related (mostly XML) files was long time requirement. Just think about Maven Release Plugin that “rewrites” the version of project during release process.

Moreover, as Maven 4 is coming, the good old Xpp3Dom parser was out of the question, as Maven 4 model contains substantial changes, and moreover, is not using anymore the Xpp3Dom parser, but the Woodstox XML parser instead. Still, Maven universe, and especially legacy Maven universe was not always “good citizen” when it comes to XML, many POMs have to be “lax parsed”, as they had (known or unknown) issues.

Maven @ IPFS (II)

Tue, 03 Feb 2026 11:55:53 +0100

This entry explains the simplest use case: “small scale publishing”. Other use cases are “global caching” and will work them out later.

Goal go-offline must go

Tue, 03 Feb 2026 10:55:53 +0100

The Maven go-offline goal is inherently bad, and will try explain it why. For related discussion, see this issue.

Maven 4 is not Maven 2

The history of this goal predates many Maven version, and it appeared around Maven 1 or Maven 2. People simply wanted to “go offline” (fx while traveling, those were the 2000s!) and pre-populate their local repository with required artifacts cached.

But, as I tried to explain my several previous articles (see Local repository), in Maven 2 and before, local repository was really just a “bunch of files”. This is not true since Maven 3.0 released in 2010!

Maven @ IPFS (I)

Thu, 22 Jan 2026 10:55:53 +0100

Lately has been toying with IPFS to achieve content sharing without centralized infrastructure. In other words, instead to free-ride on some (centralized) infrastructure that may be a public good, or some commercial offering, solve the publishing (and also “owning” and “hosting” the data) by my self. Kinda reminded me this to early 2000s, when many ran Maven repositories in their own basements, making access to their repositories fragile, with longevity accessibility and uptimes totally unpredictable. That was before Central, which consolidated but also promoted itself as single point of failure. And hence, ended up as over- and misused, see Maven Central and the Tragedy of the Commons.

Finding own footsteps

Fri, 16 Jan 2026 18:48:53 +0100

I bet many of us faced a problem, spent almost whole day on chasing it, just to discover their own footsteps around…

My case was that I had a strange issue with Njord ITs: one PR was “fine”, except the ITs failed only on single combo: Maven 4-rc-5 on Java 17. Matrix had 21 and even 25, and they were fine.

It all started by adding this “mostly harmless” repository stanza to the POM:

Maven Components and (maximum) Java bytecode

Thu, 15 Jan 2026 15:31:23 +0100

Multiple times I see people confused about “what is the java bytecode version Maven supports”?

It depends very much on which version of Maven you want to support:

Maven 3.8.9-3.9.5 uses Sisu 0.3.5 that shades ASM 5.0.2
Maven 3.9.6-3.9.7 uses Sisu 0.9.0.M2 that shades ASM 9.4
Maven 3.9.8-3.9.9 uses Sisu 0.9.0.M3 that shades ASM 9.6
Maven 3.9.10-3.9.11 uses Sisu 0.9.0.M4 that depend on ASM 9.8
Maven 3.9.12+ uses Sisu 0.9.0.M4 that depend on ASM 9.9

The ASM library is used by Sisu to “lightly introspect” classes enumerated on sisu-index for annotations. Hence, it depends on used ASM version, what bytecode versions can Sisu inspect, and in essence, what maximum bytecode level components may be, to have them picked up by Maven. Components not recognized (not being able to introspect) are silently skipped. Your friend is -Dsisu.debug that will tell you about all the issues it finds.

Lockfiles

Sat, 06 Dec 2025 15:31:23 +0100

A short attempt to explain why Maven does not have “lockfile”, at least not in a sense many other build tools and ecosystems have. Next, will try to point out features that somewhat supplement various aspects of lock files. Finally, will throw in some bait and markers where we plan to go from here.

What are lock files?

For context would like to point to ML discussion ongoing here. In general, lock files usually carry following information or aspects:

Why are MRM group repositories bad?

Sun, 09 Nov 2025 21:34:23 +0100

The notion of “group repository” was introduced by first Maven Repository Manager-like solution (then called “caching proxy”, today simply MRM): Proximity, announced on Maven devlist in 2005. Since then, almost all major MRM implementations implemented it. Some called it “group repository”, others “virtual repository”, but the fundamental idea remained the same: publish (and aggregate) multiple repositories over same URL. For brevity’s sake, I will use the term “group repository” (GR) along with “hosted repository” (HR) and “proxy repository” (PR), while some solutions out there may use slightly different (but fundamentally equivalent) terms.

Maven Local Repository (II)

Sun, 09 Nov 2025 12:34:23 +0100

The Problems

The problem with Maven local repository is manifold: it is global and is mutable. To solve these issues we chased things like “repository locking” in Maven 3.9 that proved futile, somewhat.

First problem

Originally, in Maven2 (hence the ~/.m2 directory) the local repository (by default located in ~/.m2/repository) was a “bunch of files”: it contained cached artifacts from remotes, and also installed (locally built) artifacts as well. Basically, a file was present or absent, hence it got used if present, or downloaded if absent. On the other hand, this behaviour introduced several problems too, most of them resulting in “works for me” mysterious issues, usually revealed once user nuked local repository (ie build passed on one but failed on other workstation; most often due a dependency artifact present in local repository on one workstation but absent other; while the initial issue was build POM lacking a repository declaration, from where the artifact in question should come. Basically, build depend on “state” of workstation, or more precisely, on “state” of local repository on it).

POM proliferation, part 2

Tue, 16 Sep 2025 14:34:23 +0100

This blog entry was done as a response to Pom-Pom-Pom. Note: this entry does not want to be hurting, personal or anything like that; still my native language is not english, so bear with me (and feel free to create updates to it).

Note: I talk (and reason) about Java and JARs in general, and not about C or any other language than Java.

You may want to check out part 1.

Maven Local Repository (I)

Tue, 16 Sep 2025 12:34:23 +0100

The topic is about Maven Local Repository. You know, that thing that some people insist on protecting from “pollution”.

Where to start?

Maven Local Repository, as we know it, is a mish-mash of cache and staging (locally built and installed) artifacts. Hence, no matter how much you dislike it, it is part of your “build context”, as without it, you would have no build.

Then a logical followup would be something along this: maybe we should tinker about stop using global local repository, and make it per-project instead?

POM proliferation, part 1

Wed, 02 Jul 2025 12:34:23 +0100

Where to start?

By reading that article, I frankly have no idea where to start. Take the title for example: “Brief history of POM proliferation”, and the article has nothing about it at all. So let me fill in, as history is important.

Mimir and RRF

Thu, 12 Jun 2025 12:25:23 +0100

Just to remind people about Mimir, and why they want to use it: if you remember the Never Say Never blog entry diagram:

sequenceDiagram
 autoNumber
 Session->>Session: lookup
 Session->>Local Repositories: lookup
 Session->>Remote Repositories: lookup

With Mimir on board, it changes to this:

sequenceDiagram
 autoNumber
 Session->>Session: lookup
 Session->>Local Repositories: lookup
 Session->>Mimir Cache: lookup
 Mimir Cache->>Remote Repositories: lookup and cache

This means, that nuking local repository is not an impediment anymore, as you still have everything in your Mimir cache, and building is as fast as with populated local repository.

Keep Central first!

Thu, 12 Jun 2025 12:20:23 +0100

Just an advice: when using Maven 3 (and 4) you do want to make sure Central is always first remote repository Maven would “consult”. Just add following snippet(s) to your user-wide settings.xml:

 <profiles>
 <profile>
 <id>oss-development</id>
 <repositories>
 <repository>
 <id>central</id>
 <url>https://repo.maven.apache.org/maven2/</url>
 <releases>
 <enabled>true</enabled>
 <updatePolicy>never</updatePolicy>
 </releases>
 <snapshots>
 <enabled>false</enabled>
 </snapshots>
 </repository>
 </repositories>
 <pluginRepositories>
 <pluginRepository>
 <id>central</id>
 <url>https://repo.maven.apache.org/maven2/</url>
 <releases>
 <enabled>true</enabled>
 <updatePolicy>never</updatePolicy>
 </releases>
 <snapshots>
 <enabled>false</enabled>
 </snapshots>
 </pluginRepository>
 </pluginRepositories>
 </profile>
 </profiles>

 <activeProfiles>
 <activeProfile>oss-development</activeProfile>
 </activeProfiles>

With this in your user with Maven settings, Maven will take care to keep Central first.

build != testing != publishing

Sun, 01 Jun 2025 12:15:23 +0100

This article represents my own stance, and should not be taken as any kind of “rule”.

build != testing != publishing

People tend to go for simplest solutions, and that is okay. Still, that is many times not quite feasible.

As an awkward example, that is completely viable: you may want to use Maven 4.0.x to build a Maven 3 plugin (why not?). But this is raising several questions, one of them is how to test the built plugin? Assuming you want to support Maven 3 with built plugin, it has to be Java 8 level. Using Maven 4 to run directly ITs for Java 8 is not doable, as Maven 4 requires Java 17 at runtime.

Never Say Never

Mon, 17 Mar 2025 21:55:22 +0100

This article assumes reader has basic knowledge about Maven, POM and related things. The main point is to offer high level conceptualization and explain things “why’s” and “why not”, and finally explain why you don’t want to listen to folks that tells you “never do…” (unless they are your parents).

This article is mostly about Maven 3, but mentions Maven 4 as well.

The pieces

In Maven you will read about following very important things:

Maven4 ante portas! (Part 1)

Sat, 07 Dec 2024 13:00:00 +0100

Maven4 is coming, so it may be time to explain some of the changes it will bring on. I’d like to start from “user facing” end, the mvn command and what has changed (visible and invisible changes).

How it was: Maven3

In short, Maven3 has a well known mvn (and mvn.cmd Windows counterpart) script in place that users invoke. This script observed some of the environment variables (think MAVEN_OPTS and others), observed mavenrc file, tried to find .mvn directory and also load .mvn/jvm.config from it, if existed, and finally, it fired up Java calling ClassWorlds launcher class and setting the launcher configuration to conf/m2.conf file.

Handling sensitive data in Maven

Sat, 07 Dec 2024 12:56:00 +0100

Maven is well known for flexible configurability. Many times, those configuration and setting files can contain sensitive data (like passwords). Long time ago, it was even common practice to put gpg.passphrase in POM properties! The latest GPG plugin releases introduced bestPractice parameter, that when enabled, prevents getting the GPG passphrase in “insecure” ways. Furthermore, new versions of GPG plugin will flip the default value and finally remove all the related parameters (see MGPG-146 for details).

Migrating to Maven 3, part 3

Mon, 09 Sep 2024 19:16:22 +0200

From Maven perspective, whether a component is defined as Plexus component (via Plexus XML, crafted manually or during build with plexus-component-metadata Maven Plugin) or JSR330 component, does not matter.

But there is a subtle difference.

Plexus components store their “definition” in XML that is usually embedded in JAR, so Plexus DI has not much to do aside to parse the XML and use Java usual means to instantiate it, populates/wires up requirements and publish it.

What is MIMA (and what is not)?

Sat, 07 Sep 2024 21:55:22 +0100

Here am trying to explain what is Maveniverse/MIMA, but also to explain what it is not.

There is Maven, as we know it, and there are libraries that Maven uses to be “Maven as we know it”, like Resolver is. Many times, use case requires use of “Resolver only” without all the fuss and fluff of Maven. Historically, there was the ServiceLocator, that made Resolver somewhat reusable outside of Maven, but then MRESOLVER-157 came in, so what now?

Migrating to Maven 3, part 2

Sat, 07 Sep 2024 20:55:22 +0100

A small fable for myself and others…

The Takari Polyglot Maven 0.7.1 was released not so long ago, and it contained one trivial change, this pull request. The goal was to fix following issue: JRuby folks had some problem, that could be solved among other ways, by creating a “custom JRuby Polyglot Maven distribution” (see related pull request).

But, while testing this, I came to strange conclusion: the Polyglot extension did work when loaded up through .mvn/extensions.xml, but did not work when loaded up from core (when it was added to lib/ext of custom Maven distribution). Fix seemed simple, raised the priority of TeslaModelProcessor and done. Polyglot started working when in lib/ext, so I released 0.7.1.

Migrating to Maven 3, part 1

Sat, 07 Sep 2024 17:55:22 +0100

As weird as title sounds, given Maven 4 is “around the corner”, the sad reality is that there are still way too many libraries and plugins in “Maven ecosystem” that rely on some sort of “compatibility” layers (and deprecated things) in Maven 3. For example Eclipse Sisu is fully functional and in charge since Maven 3.1.0 (released in 2013, when last missing piece, support for “sisu index” was added). Maven project during it’s existence did pile up some of the debts, or in other words, “moved past” some well known libraries. Plexus DI Container and Wagon being the most notable examples.

Very simple CI setup

Sat, 07 Sep 2024 15:55:22 +0100

I’d just like to throw in a short explanation how (IMHO) should organize CI jobs for simple Maven projects for better and faster turnaround.

People usually “throw up a matrix” and just run mvn verify -P run-its. Sure, that is really the simplest.

But what if, our matrix is big? Or what if we want to utilize one of the Maven basics, the Local repository?

I wanted to mimic what I do locally: I usually build/install with latest stable Maven (3.9.9 currently) and latest LTS Java (21.0.4 currently), and then perform a series of ITs/test/assessments, to ensure the thing I build covers all combos of Maven/Java/whatever.

How to add new Maven lifecycle mapping

Sat, 07 Sep 2024 14:55:22 +0100

Ever repeating question from plugin/extension developers is “how to add new packaging” (in a “modern way”). For ages we did it by manually crafting plexus.xml in the plugin or extension JAR, that was not only error-prone but also tedious. But, indeed it had a great value as one could easily filter the XML (ie filtering plugin versions). But, plexus XML is plexus XML… yuck. So what now?

Here is an example from Eclipse Tycho: The tycho-maven-plugin originally defined this Plexus XML (and yes, it did filter for versions as well):