maven
Frameworkapache/maven
A build automation and project management tool primarily for Java.
Overview
Maven is a software project management and comprehension tool based on the Project Object Model (POM). It centralizes build, reporting, and documentation tasks, enabling reproducible builds and dependency management.
README Preview
\nApache Maven\n============\n\n[][license]\n[](https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/maven/maven/README.md)\n\n- [master](https://github.com/apache/maven) = 4.1.x\n[][build]\n[][gh-build]\n\n- [4.0.x](https://github.com/apache/maven/tree/maven-4.0.x): \n[](https://central.sonatype.com/artifact/org.apache.maven/apache-maven)\n[][build-4.0]\n[][gh-build-4.0]\n\n- [3.10.x](https://github.com/apache/maven/tree/maven-3.10.x):\n[][build-3.10]\n[][gh-build-3.10]\n\n- [3.9.x](https://github.com/apache/maven/tree/maven-3.9.x): \n[](https://central.sonatype.com/artifact/org.apache.maven/apache-maven)\n[][build-3.9]\n[][gh-build-3.9]\n\nApache Maven is a software project management and comprehension tool. Based on\nthe concept of a project object model (POM), Maven can manage a project's\nbuild, reporting and documentation from a central piece of information.\n\nIf you think you have found a bug, please file an issue in the [Maven Issue Tracker](https://github.com/apache/maven/issues).\n\nDocumentation\n-------------\n\nMore information can be found on [Apache Maven Homepage][maven-home].\nQuestions related to the usage of Maven should be posted on\nthe [Maven User List][users-list].\n\n\nWhere can I get the latest release?\n-----------------------------------\nYou can download the release source from our [download page][maven-download].\n\nContributing\n------------\n\nIf you are interested in the development of Maven, please consult the\ndocumentation first and afterward you are welcome to join the developers\nmailing list to ask questions or discuss new ideas/features/bugs etc.\n\nTake a look into the [contribution guidelines](CONTRIBUTING.md).\n\nLicense\n-------\nThis code is under the [Apache License, Version 2.0, January 2004][license].\n\nSee the [`NOTICE`](./NOTICE) file for required notices and attributions.\n\nDonations\n---------\nDo you like Apache Maven? Then [donate back to the ASF](https://www.apache.org/founda
FAQ (5)
TroubleshootingHow to fix embedded Maven 3.10.0 ignoring `--color=yes` and producing no ANSI output with `MavenCli.doMain`?
This is a regression in Maven 3.10.0. After the JAnsi-to-JLine migration, MessageUtils.isColorEnabled() requires both colorEnabled and a non-null Terminal. MavenCli.main(...) installs the terminal, but embedded calls through MavenCli.doMain(...) do not, so --color=yes sets the flag but ANSI output remains disabled.
Fix: use a Maven 3.10.x build that includes PR #13358, or the corresponding fixed release. The fix makes doMain install a dumb-color JLine terminal through MessageUtils.systemInstall(Terminal) for the embedded call and remove it afterwards; no new API is required.
Temporary workarounds:
1. Downgrade the embedded Maven runtime to 3.9.x, for example maven-embedder 3.9.16, where --color=yes is honoured.
2. Run Maven forked instead of using the embedded executor (EmbeddedMavenExecutor); the forked executor works correctly on 3.10.0.
3. If maintaining a custom embedder, install a color-capable JLine Terminal with MessageUtils.systemInstall(...) before calling doMain and restore/remove it in a finally block. Prefer upgrading to the patched Maven version because this uses internal Maven API.
Verify the runtime version with mvn -v and rerun the embedded command with --color=yes.
TroubleshootingHow to fix 'ArtifactFilteredOutException: prefixes: Path NOT allowed from central' for internal artifacts in Maven 3.10.0?
Maven 3.10.0 uses Resolver 2.0.x, where remote-repository prefix filtering is enabled by default. If Artifactory/Nexus serves a prefixes.txt generated only from the public Maven Central index, internal artifacts in an aggregated virtual repository are blocked even though they exist and are directly downloadable.
Immediate workaround: disable prefix filtering for the build:
mvn -Daether.remoteRepositoryFilter.prefixes.enabled=false clean verifyTo apply it persistently, add this line to .mvn/maven.config:
-Daether.remoteRepositoryFilter.prefixes.enabled=falseIf necessary, all remote-repository filters can be disabled with:
mvn -Daether.remoteRepositoryFilter.enabled=false clean verifyThis is only a workaround. The permanent fix is for the repository manager to serve a correct prefixes.txt that includes internal artifact paths, or to stop serving an incorrect prefix file for the aggregated repository. Downgrading to Maven 3.9.x also avoids the issue because it uses Resolver 1.x, which does not pull prefix files by default.
TroubleshootingHow to fix NullPointerException from MojoExecution.getPlugin().getDependencies() on the second plugin execution in Maven 4?
This occurs in Maven 4.0.0-rc-7 when the plugin class realm is served from PluginRealmCache. The cache restores the class realm and artifacts, but not the resolver dependency node, so PluginDescriptor.getDependencyNode() is null on subsequent executions. Upgrade to a Maven 4 build that includes the fix, where PluginRealmCache.CacheRecord retains the dependency node and DefaultMavenPluginManager.setupPluginRealm() restores it. If building Maven from source, apply the upstream fix by storing the DependencyNode in the cache record and restoring it alongside the cached realm. As a temporary workaround, avoid binding the same plugin multiple times in one build, or combine those plugin executions.
TroubleshootingWhy does `mvnup check` report "POM(s) modified" and "Plugin upgrades applied" during a dry run?
This is a misleading-output bug in Apache Maven 4.0.0-rc-7. mvnup check performs a dry run and does not write POM files, even though its report says that upgrades were applied and POMs were modified. Verify with cp pom.xml /tmp/before.xml && mvnup check && diff /tmp/before.xml pom.xml; no differences should be reported. The fix tracks dry-run state and changes the wording to planned-action text such as "would upgrade" and "POM(s) would be modified". Upgrade to a Maven release containing PR "fix: clarify mvnup check dry-run output" (or build Maven from source with that PR). Until then, treat check output as a preview only; run the applicable apply/write goal only when you want changes written.
TroubleshootingHow do I fix "Unknown packaging" when contributing a packaging through PackagingProvider in a Maven 4 extension?
This is a bug in Maven 4.0.0-rc-7 and current master: DefaultPackagingRegistry.lookup() checks only the legacy Sisu LifecycleMapping and ignores the injected List<PackagingProvider>, so contributed packagings such as app-client fail with Unknown packaging: app-client.
Fix:
1. Upgrade Maven to a release containing PR #13319, or build Maven from that branch if no release is available yet.
2. The patch makes DefaultPackagingRegistry read the injected PackagingProvider instances and resolve their packagings by ID before falling back to LifecycleMapping.
Workaround until the fix is released: keep the Maven 3/Plexus registration in META-INF/plexus/components.xml and register the custom packaging ID as a LifecycleMapping component. Do not rely solely on PackagingProvider/TypeProvider. Rebuild the extension after restoring that descriptor. This affects packagings used by maven-acr-plugin, maven-rar-plugin, maven-jmod-plugin, and maven-jlink-plugin.