아파치 메이븐

아파치 메이븐

개발자	Apache 소프트웨어 재단
초기 릴리즈	2004년 7월 13일; 18년 전(2004-07-13)
안정된 릴리스	3.8.6 / 2022년 6월 6일; 58일 전(2022-06-06)[1]
저장소	gitbox.apache.org/repos/asf/maven.git
기입처	자바
유형	빌드 툴
면허증.	Apache 라이센스 2.0
웹 사이트	maven.apache.org

Maven은 주로 Java 프로젝트에 사용되는 빌드 자동화 도구입니다.Maven은 C#, Ruby, Scala 및 기타 언어로 작성된 프로젝트를 구축하고 관리하는 데도 사용할 수 있습니다.Maven 프로젝트는 Apache Software Foundation이 주최하고 있으며, 이전에는 자카르타 프로젝트의 일부였습니다.

Maven은 소프트웨어 구축의 두 가지 측면, 즉 소프트웨어 구축 방법과 의존성에 대해 설명합니다.Apache Ant와 같은 이전 도구와는 달리 빌드 절차에 규칙을 사용합니다.예외만 지정해야 합니다.XML 파일에는 빌드 중인 소프트웨어 프로젝트, 다른 외부 모듈 및 컴포넌트에 대한 의존성, 빌드 순서, 디렉토리 및 필요한 플러그인이 기술되어 있습니다.여기에는 코드 컴파일 및 패키징과 같은 명확한 작업을 수행하기 위한 사전 정의된 목표가 포함되어 있습니다.Maven은 Maven 2 Central Repository와 같은 하나 이상의 저장소에서 Java 라이브러리와 Maven 플러그인을 동적으로 다운로드하여 로컬 ^[2]캐시에 저장합니다.다운로드된 아티팩트의 이 로컬 캐시는 로컬 프로젝트에서 만든 아티팩트로 업데이트할 수도 있습니다.공용 저장소도 업데이트할 수 있습니다.

Maven은 표준 입력을 통해 제어 가능한 모든 애플리케이션을 사용할 수 있는 플러그인 기반 아키텍처를 사용하여 구축되었습니다.Maven ^[3]2에는 C/C++ 네이티브 플러그인이 유지됩니다.

Gradle이나 빌드 툴로서의 sbt와 같은 대체 테크놀로지는 XML에 의존하지 않고 Maven이 도입한 주요 개념을 유지합니다.Apache Ivy에서는 Maven ^[4]저장소를 지원하는 전용 종속 관리자도 개발되었습니다.

Apache Maven은 재현 가능한 ^[5][6]빌드를 지원합니다.

역사

메이븐의 중앙 저장소에 있는 아티팩트의 수가 빠르게 증가하고 있습니다.

Maven은 Jason van Zyl에 의해 2002년에 Apache Turvine의 하위 프로젝트로 시작되었습니다.2003년에는 Apache Software Foundation 프로젝트에 대한 투표를 거쳐 최상위 프로젝트로 승인되었습니다.2004년 7월, Maven의 릴리스는 중요한 첫 번째 이정표인 v1.0이었습니다.Maven 2는 베타 사이클로 약 6개월 후에 2005년 10월에 v2.0으로 선언되었습니다.Maven 3.0은 2010년 10월에 출시되었으며 대부분 Maven 2와 역호환됩니다.

Maven 3.0 정보는 2008년에 유출되기 시작했습니다.8개의 알파 버전이 출시된 후, 2010년 4월에 Maven 3.0의 첫 번째 베타 버전이 출시되었습니다.Maven 3.0은 핵심 Project Builder 인프라스트럭처를 재작업하여 POM의 파일 기반 표현과 메모리 내 객체 표현을 분리하였습니다.이로 인해 Maven 3.0 애드온이 비 XML 기반 프로젝트 정의 파일을 활용할 수 있는 가능성이 확대되었습니다.제안된 언어에는 Ruby(Jason van Zyl이 이미 개인 프로토타입으로 제공), YAML 및 Groovy가 포함됩니다.

Maven 3과 Maven 2의 하위 호환성을 보장하기 위해 특별히 주의를 기울였다.대부분의 프로젝트에서 Maven 3으로 업그레이드하는 경우 프로젝트 구조를 조정할 필요가 없습니다.Maven 3의 첫 번째 베타 버전에서는 멀티 코어 머신에서 구성 가능한 수의 코어를 활용하여 대규모 멀티 모듈 프로젝트에 특히 적합한 병렬 빌드 기능이 도입되었습니다.

구문

메이븐 프로젝트는 POM(Project Object Model)을 사용하여 구성되며, POM은pom.xml-file. 예제 파일은 다음과 같습니다.

<>project>, <.!--모델 버전은 항상 4.0.0 메이븐 2.x POMs에><, modelVersion>, 4.0.0<, /modelVersion>,>!고유하게 이 프로젝트를 식별하는 값의 집단입니다 을 예를 들면 프로젝트죠 좌표,<>groupId>, com.mycompany.app<, /groupId>, <, artifactId>, my-app<, /artifactId>,<>버전, 1.0<, /version>,>입니다. 도서관 의존성,입니다.;<>dependencies>, <, dependency>,>!--co.필요한 라이브러리의 표준 --> <groupId> junit </groupId> </artifactId> junit </artifactId> <버전> 3.8.1 </version> <!-- 이 의존관계는 테스트 실행 및 컴파일에만 사용됩니다. --> <scope> </scope> </dependency> </dependency> </> </> </> </>

이 POM은 프로젝트(좌표) 및 JUnit 프레임워크에 대한 의존성에 대한 고유 식별자만 정의합니다.그러나 이미 프로젝트를 구축하고 프로젝트와 관련된 유닛 테스트를 실행하는 데 충분합니다.Maven은 Configuration에 대한 Convention over Configuration(Convention over Configuration)이라는 개념을 수용함으로써 이를 실현합니다.즉, Maven은 프로젝트 구성에 기본값을 제공합니다.

통상적인 Maven 프로젝트의 디렉토리 구조에는, 다음의 디렉토리 엔트리가 있습니다.

Maven이 자동으로 생성한 Java 프로젝트의 디렉토리 구조

명령어mvn package모든 Java 파일을 컴파일하여 테스트를 실행하고 성과물 코드와 리소스를 패키지화합니다.target/my-app-1.0.jar(architectId가 my-app이고 버전이 1.0이라고 가정합니다).

사용자는 Maven을 사용하여 프로젝트에 대한 구성만 제공하고 구성 가능한 플러그인은 프로젝트 컴파일, 타깃 디렉토리 청소, 유닛 테스트 실행, API 문서 생성 등의 실제 작업을 수행합니다.일반적으로 사용자가 직접 플러그인을 작성할 필요는 없습니다.이것을 Ant 및 make와 대조하여 상기 작업을 수행하기 위한 필수 절차를 작성합니다.

설계.

프로젝트 객체 모델

프로젝트 객체 모델(POM)은 단일 프로젝트에 대한 모든 구성을 제공합니다.일반 구성은 프로젝트 이름, 소유자 및 다른 프로젝트에 대한 종속성을 포함합니다.또한 플러그인으로 구현되는 빌드 프로세스의 개별 단계를 구성할 수도 있습니다.예를 들어 컴파일러 플러그인이 컴파일에 Java 버전 1.5를 사용하도록 구성하거나 일부 장치 테스트가 실패하더라도 프로젝트를 패키징하도록 지정할 수 있습니다.

대규모 프로젝트는 각각 자체 POM을 가진 여러 모듈 또는 하위 프로젝트로 분할해야 합니다.그런 다음 루트 POM을 작성하여 하나의 명령어로 모든 모듈을 컴파일할 수 있습니다.POM은 다른 POM에서 설정을 상속할 수도 있습니다.기본적으로 모든 POM은 Super^[8] POM에서 상속됩니다.Super POM은 기본 소스 디렉토리, 기본 플러그인 등의 기본 설정을 제공합니다.

플러그인

Maven의 대부분의 기능은 플러그인에 있습니다.플러그인은 다음 명령을 사용하여 실행할 수 있는 목표 집합을 제공합니다.mvn [plugin-name]:[goal-name]예를 들어 Java 프로젝트는 컴파일러 플러그인의 컴파일 목표를^[9] 사용하여 컴파일할 수 있습니다.mvn compiler:compile.

빌드, 테스트, 소스 제어 관리, 웹 서버 실행, Eclipse 프로젝트 파일 생성 ^[10]등을 위한 Maven 플러그인이 있습니다.플러그인은 의 <플러그인> 섹션에서 도입 및 설정됩니다.pom.xml일부 기본 플러그인은 기본적으로 모든 프로젝트에 포함되어 있으며 적절한 기본 설정을 가지고 있습니다.

단, 각 목표를 수동으로 실행해야 하는 소프트웨어 프로젝트의 구축, 테스트 및 패키징의 전형적인 빌드 시퀀스가 있다면 번거롭습니다.

• mvn compiler:compile
• mvn surefire:test
• mvn jar:jar

Maven의 라이프 사이클 개념은 이 문제를 처리합니다.

플러그인은 Maven을 확장하는 주요 방법입니다.Maven 플러그인은 org.apache.maven을 확장하여 개발할 수 있습니다.plugin.AbstractMojo 클래스애플리케이션 서버를 실행하는 클라우드 기반 가상 머신을 생성하기 위한 Maven 플러그인의 예 코드와 설명은 클라우드 가상 ^[11]머신의 개발 및 관리 자동화 기사에 나와 있습니다.

라이프 사이클 구축

빌드 라이프 사이클은 목표 실행을 지시하기 위해 사용할 수 있는 명명된 단계 목록입니다.Maven의 표준 라이프 사이클 중 하나는 다음과 같은 단계를 포함하는 기본 라이프 사이클입니다.^[12]

• 입증하다
• 생성-유효과의
• 프로세스 조정
• 생성-유효과의
• 프로세스 조정
• 컴파일하다
• 프로세스 테스트의
• 프로세스 테스트의
• 테스트 테스트
• 시험
• 패키지
• 설치하다
• 전개하다

플러그인이 제공하는 목표는 라이프 사이클의 여러 단계에 연관지을 수 있습니다.예를 들어 기본적으로 목표 "compiler:compile"은 "compile" 단계와 관련지어지며 목표 "surefire:test"는 "test" 단계와 관련지어집니다.언제?mvn test명령이 실행되면 Maven은 "테스트" 단계까지 각 단계와 관련된 모든 목표를 실행합니다.이 경우 Maven은 "process-resources" 단계와 관련된 "resources:resources" 목표를 실행한 다음 "compiler:compile" 등을 실행하여 "surefire:test" 목표를 최종적으로 실행합니다.

Maven은 프로젝트 청소 및 프로젝트 사이트 생성을 위한 표준 단계도 가지고 있습니다.클리닝이 기본 라이프 사이클의 일부인 경우 프로젝트는 빌드될 때마다 클리닝됩니다.이것은 분명히 바람직하지 않기 때문에, 클리닝에는 독자적인 라이프 사이클이 주어져 있습니다.

표준 라이프 사이클을 통해 프로젝트를 처음 접하는 사용자는 단일 명령어를 발행하여 모든 Maven 프로젝트를 정확하게 구축, 테스트 및 설치할 수 있습니다.mvn install디폴트로는 Maven은 생성된 JAR 파일과 WAR 파일로 POM 파일을 패키지합니다.diet4j와^[13] 같은 도구는 이 정보를 사용하여 모든 프로젝트 코드를 포함하는 "uber" jar를 필요로 하지 않고 런타임에 Maven 모듈을 재귀적으로 해결하고 실행할 수 있습니다.

의존 관계

Maven의 주요 기능은 의존관계 관리입니다.Maven의 의존성 처리 메커니즘은 소프트웨어 라이브러리 또는 모듈과 같은 개별 아티팩트를 식별하는 좌표계를 중심으로 구성되어 있습니다.위의 POM 예에서는 JUnit 좌표를 프로젝트의 직접적인 종속성으로 참조하고 있습니다.예를 들어 Hibernate 라이브러리가 필요한 프로젝트는 POM에서 Hibernate의 프로젝트 좌표를 선언하기만 하면 됩니다.Maven은 자동으로 Hibernate 자체에 필요한 의존관계 및 의존관계(Transitive Dependency라고 함)를 다운로드하여 사용자의 로컬 저장소에 저장합니다.Maven 2 Central^[2] Repository는 기본적으로 라이브러리를 검색하기 위해 사용되지만 POM 내에서 사용할 저장소(예: 회사-개인 저장소)를 구성할 수 있습니다.

Maven과 Ant의 근본적인 차이점은 Maven의 설계에서는 모든 프로젝트가 특정 구조와 지원되는 일련의 태스크 워크플로우(소스 제어, 프로젝트 컴파일, 유닛 테스트 등)를 갖는 것으로 간주한다는 것입니다.실제로 대부분의 소프트웨어 프로젝트는 이러한 작업을 지원하며 실제로 잘 정의된 구조를 가지고 있지만, Maven은 이 구조와 운영 구현 세부사항을 POM 파일에 정의해야 합니다.따라서 Maven은 프로젝트를 정의하는 방법과 모든 ^[14]프로젝트에서 일반적으로 지원되는 워크플로우 목록에 대한 규약에 의존합니다.

중앙 저장소 검색 ^[15]엔진과 같은 검색 엔진이 있으며, 이 엔진은 다양한 오픈 소스 라이브러리와 프레임워크의 좌표를 찾는 데 사용할 수 있습니다.

단일 머신에서 개발된 프로젝트는 로컬 저장소를 통해 서로 의존할 수 있습니다.로컬 저장소는 다운로드된 종속성에 대한 캐시 역할과 로컬로 구축된 아티팩트의 중앙 집중식 스토리지 공간 역할을 모두 수행하는 단순한 폴더 구조입니다.메이븐 명령어mvn install는 프로젝트를 빌드하여 로컬저장소에 바이너리를 배치합니다.그러면 다른 프로젝트에서도 POM에 좌표를 지정하여 이 프로젝트를 활용할 수 있습니다.

상호 운용성

Java 프로그래밍 언어를 대상으로 하는 몇 가지 인기 있는 통합 개발 환경(IDE)에 대한 추가 기능은 Maven과 IDE의 빌드 메커니즘 및 소스 편집 도구를 통합하여 Maven이 IDE 내에서 프로젝트를 컴파일할 수 있도록 하며, 또한 코드 완료에 대한 클래스 경로 설정, 컴파일러 오류 강조 등을 가능하게 합니다.

Maven과의 개발을 지원하는 일반적인 IDE의 예는 다음과 같습니다.

• 이클립스
• 넷빈즈
• 인텔리J 아이디어
• JBuilder
• JDeveloper(버전 11.1.2)
• 마이클립스
• Visual Studio 코드

이러한 애드온은 POM을 편집하거나 POM을 사용하여 IDE 내에서 프로젝트의 전체 종속성 집합을 직접 확인할 수도 있습니다.

IDE가 컴파일을 하지 않게 되면, IDE 의 내장 기능의 일부가 없어집니다.예를 들어, Eclipse의 JDT에는 단일 Java 소스 파일을 편집한 후 다시 컴파일할 수 있는 기능이 있습니다.많은 IDE는 Maven이 선호하는 폴더 계층 대신 평평한 프로젝트 집합에서 작동합니다.이로 인해 Maven을 ^[16][17][18]사용할 때 IDE에서 SCM 시스템을 사용하는 것이 복잡해집니다.

「 」를 참조해 주세요.

• 아파치 컨티뉴
• 아파치 젤리
• 허드슨
• 젠킨스
• 빌드 자동화 소프트웨어 목록

레퍼런스

추가 정보

• O'Brien, Tim; et al. "Maven: The Complete Reference". Sonatype.com. Sonatype. Retrieved 15 March 2013.
• Maven: The Definitive Guide. Sonatype Company. O'Reilly Media, Inc. 2009. p. 470. ISBN 9780596551780. Retrieved 2013-04-17.{{cite book}}: CS1 유지보수: 기타 (링크)
• Van Zyl, Jason (2008-10-01), Maven: Definitive Guide (first ed.), O'Reilly Media, pp. 468, ISBN 978-0-596-51733-5
• "Running JUnit tests from Maven2". JUnit in Action (2nd ed.). Manning Publications. 2011. pp. 152–168. ISBN 978-1-935182-02-3.
• Maven Build Customization. Packt. 2013. pp. 1–250. ISBN 9781783987221.
• Mastering Apache Maven 3. Packt. 2014. p. 298. ISBN 9781783983865.

외부 링크

• 공식 웹사이트
• 5분 후 메이븐