개요
Maven은 프로젝트 객체 모델(POM) 기반의 소프트웨어 프로젝트 관리 도구로, 빌드, 보고서 및 문서를 중앙에서 관리하며 재현 가능한 빌드와 의존성 관리를 지원합니다.
README 미리보기
\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)
문제 해결임베디드 Maven 3.10.0이 `--color=yes`를 무시하고 `MavenCli.doMain` 사용 시 ANSI 출력을 생성하지 않는 문제를 해결하는 방법은?
이것은 Maven 3.10.0의 회귀입니다. JAnsi에서 JLine으로 마이그레이션한 이후, MessageUtils.isColorEnabled()는 colorEnabled와 null이 아닌 Terminal을 모두 요구합니다. MavenCli.main(...)은 터미널을 설치하지만 MavenCli.doMain(...)을 통한 임베디드 호출은 설치하지 않으므로, --color=yes가 플래그를 설정해도 ANSI 출력은 비활성화된 상태로 유지됩니다.
해결 방법: PR #13358이 포함된 Maven 3.10.x 빌드 또는 해당 수정이 반영된 릴리스를 사용하세요. 이 수정은 doMain이 임베디드 호출을 위해 MessageUtils.systemInstall(Terminal)을 통해 dumb-color JLine 터미널을 설치하고 이후에 제거하도록 하며, 새로운 API는 필요하지 않습니다.
임시 해결 방법:
1. 임베디드 Maven 런타임을 3.9.x로 다운그레이드하세요. 예를 들어 maven-embedder 3.9.16에서는 --color=yes가 정상적으로 적용됩니다.
2. 임베디드 실행기(EmbeddedMavenExecutor)를 사용하는 대신 Maven을 forked로 실행하세요. forked 실행기는 3.10.0에서 올바르게 작동합니다.
3. 커스텀 임베더를 유지 관리하는 경우, doMain을 호출하기 전에 MessageUtils.systemInstall(...)로 컬러를 지원하는 JLine Terminal을 설치하고 finally 블록에서 복원하거나 제거하세요. 이 방법은 Maven 내부 API를 사용하므로 패치된 Maven 버전으로 업그레이드하는 것이 좋습니다.
mvn -v로 런타임 버전을 확인하고 --color=yes를 사용하여 임베디드 명령을 다시 실행하세요.
문제 해결Maven 3.10.0에서 내부 아티팩트에 대한 'ArtifactFilteredOutException: prefixes: Path NOT allowed from central' 오류를 해결하는 방법
Maven 3.10.0은 Resolver 2.0.x를 사용하며, 이 버전에서는 원격 저장소 접두사 필터링이 기본적으로 활성화되어 있습니다. Artifactory/Nexus가 공용 Maven Central 인덱스만으로 생성된 prefixes.txt를 제공하는 경우, 집계 가상 저장소의 내부 아티팩트가 실제로 존재하고 직접 다운로드할 수 있더라도 차단됩니다.
즉각적인 해결 방법: 빌드에서 접두사 필터링을 비활성화합니다:
mvn -Daether.remoteRepositoryFilter.prefixes.enabled=false clean verify영구적으로 적용하려면 .mvn/maven.config에 다음 줄을 추가하세요:
-Daether.remoteRepositoryFilter.prefixes.enabled=false필요한 경우 다음 명령으로 모든 원격 저장소 필터를 비활성화할 수 있습니다:
mvn -Daether.remoteRepositoryFilter.enabled=false clean verify이는 임시 해결 방법일 뿐입니다. 영구적인 해결책은 저장소 관리자가 내부 아티팩트 경로가 포함된 올바른 prefixes.txt를 제공하거나, 집계 저장소에 대해 잘못된 접두사 파일의 제공을 중단하는 것입니다. Maven 3.9.x로 다운그레이드하는 것도 문제를 피하는 방법입니다. Maven 3.9.x는 Resolver 1.x를 사용하며, Resolver 1.x는 기본적으로 접두사 파일을 가져오지 않기 때문입니다.
문제 해결Maven 4에서 두 번째 플러그인 실행 시 MojoExecution.getPlugin().getDependencies()에서 발생하는 NullPointerException을 해결하는 방법은?
이 문제는 플러그인 클래스 렐름이 PluginRealmCache에서 제공될 때 Maven 4.0.0-rc-7에서 발생합니다. 캐시는 클래스 렐름과 아티팩트를 복원하지만 리졸버 디펜던시 노드는 복원하지 않으므로, 이후 실행에서는 PluginDescriptor.getDependencyNode()가 null이 됩니다. PluginRealmCache.CacheRecord가 디펜던시 노드를 유지하고 DefaultMavenPluginManager.setupPluginRealm()이 이를 복원하는 수정 사항이 포함된 Maven 4 빌드로 업그레이드하세요. 소스로부터 Maven을 빌드하는 경우, DependencyNode를 캐시 레코드에 저장하고 캐시된 렐름과 함께 복원하는 방식으로 업스트림 수정을 적용하세요. 임시 해결 방법으로는 하나의 빌드에서 동일한 플러그인을 여러 번 바인딩하지 않거나, 해당 플러그인 실행들을 하나로 결합하세요.
문제 해결`mvnup check`가 dry run 중에 "POM(s) modified"와 "Plugin upgrades applied"를 보고하는 이유는 무엇인가요?
이것은 Apache Maven 4.0.0-rc-7의 오해를 불러일으키는 출력 버그입니다. mvnup check는 dry run을 수행하며 POM 파일을 쓰지 않지만, 보고서에는 업그레이드가 적용되었고 POM이 수정되었다고 표시됩니다. cp pom.xml /tmp/before.xml && mvnup check && diff /tmp/before.xml pom.xml로 확인하세요. 차이점이 보고되지 않아야 합니다. 이 수정은 dry-run 상태를 추적하고 문구를 "would upgrade" 및 "POM(s) would be modified"와 같은 계획된 작업 텍스트로 변경합니다. PR "fix: clarify mvnup check dry-run output"이 포함된 Maven 릴리스로 업그레이드하세요(또는 해당 PR을 적용하여 소스에서 Maven을 빌드하세요). 그때까지는 check 출력을 미리보기로만 취급하세요. 변경 사항을 쓰고 싶을 때만 해당하는 apply/write goal을 실행하세요.
문제 해결Maven 4 extension에서 PackagingProvider를 통해 패키징을 제공할 때 "Unknown packaging" 오류를 어떻게 해결하나요?
이것은 Maven 4.0.0-rc-7과 현재 master의 버그입니다: DefaultPackagingRegistry.lookup()이 레거시 Sisu LifecycleMapping만 확인하고 주입된 List<PackagingProvider>를 무시하므로, app-client와 같이 기여된 패키징이 Unknown packaging: app-client 오류로 실패합니다.
수정 방법:
1. PR #13319가 포함된 릴리스로 Maven을 업그레이드하거나, 아직 릴리스가 없다면 해당 브랜치에서 Maven을 빌드하세요.
2. 이 패치는 DefaultPackagingRegistry가 주입된 PackagingProvider 인스턴스를 읽고 LifecycleMapping으로 폴백하기 전에 ID로 해당 패키징을 해석하도록 합니다.
수정이 릴리스될 때까지의 우회 방법: META-INF/plexus/components.xml에 Maven 3/Plexus 등록을 유지하고 사용자 지정 패키징 ID를 LifecycleMapping 컴포넌트로 등록하세요. PackagingProvider/TypeProvider에만 의존하지 마세요. 해당 디스크립터를 복원한 후 확장을 다시 빌드하세요. 이 문제는 maven-acr-plugin, maven-rar-plugin, maven-jmod-plugin, maven-jlink-plugin에서 사용하는 패키징에 영향을 미칩니다.