pom.xml 및 settings.xml
pom.xml 및 setting.xml은 Maven의 가장 중요한 구성 파일로 말할 수 있으며 Maven의 핵심 기능을 결정합니다. 이전 기사에서는 Pom.xml 및 Settings.xml의 내용을 단편으로 언급했지만 모두 간단히 언급되며 학습과 연구는 자세히 설명되지 않습니다. 이 기사의 목적은이 두 가지 중요한 구성 파일을 자세히 연구하는 것입니다. 이 두 구성 파일은 많은 Maven 주제로 이어질 수 있습니다.
Maven 좌표
먼저 Maven 좌표를 사용해야하는 이유에 대해 이야기 해 봅시다.
Maven World에는 매우 많은 수의 구성 요소, 즉 일부 Jar, War 및 일반적으로 사용되는 다른 파일이 있습니다. Maven이 이러한 구성 요소에 대한 좌표 개념을 소개하기 전에 이러한 모든 구성 요소를 고유하게 식별하기 위해 어떤 방법도 사용할 수 없습니다. 따라서 Spring Dependencies를 사용해야하는 경우 Spring 공식 웹 사이트로 이동하여 검색하십시오. log4j 종속성을 사용해야하는 경우 Apache 공식 웹 사이트로 이동하여 검색하십시오. 각 웹 사이트의 다양한 스타일로 인해 웹 페이지를 검색하고 탐색하는 데 많은 시간이 소요됩니다. 통일 규범과 규칙이 없으면 작업을 자동화 할 수 없으며 반복적 인 노동은 기계에 맡겨야합니다.
Maven은 일련의 규칙을 정의합니다. 세계의 모든 구성 요소는 Maven 좌표로 고유하게 식별 될 수 있습니다. Maven 좌표 요소에는 GroupId, artifactid, 버전, 포장 및 분류기가 포함됩니다. 이제 올바른 요소 좌표를 제공하는 한 Maven은 해당 구성 요소를 찾을 수 있습니다. 다운로드 장소는 Maven 자체에 중앙 창고 "http://repo1.maven.org/maven2"의 내장 주소가 있습니다. Central Warehouse에는 세계에서 인기있는 오픈 소스 프로젝트 구성 요소가 많이 포함되어 있습니다. Mavne은 필요할 때 다운로드합니다. 물론, 자신의 중앙 창고 주소를 구성하고 자신의 중앙 창고에서 구성 요소를 다운로드 할 수도 있습니다.
예를 들어, Spring의 맥락 :
<pectionency> <groupid> org.springframework </groupid> <artifactid> spring-context </artifactid> <버전> 4.2.6. release </version> </dependency
부하 직원의 요소를 살펴보십시오.
이것은 대략 Maven 좌표의 개념입니다. Maven 좌표를 이해하는 것은 Maven을 이해하는 데 매우 중요한 단계입니다.
전이 의존성
전이 의존성이란 무엇입니까? 예를 들어 봄을 가져 가십시오. 스프링을 사용할 때는 다른 오픈 소스 클래스 라이브러리에 의존합니다. 이 작업을 수행하는 두 가지 방법이 있습니다.
1. 모든 스프링 병이 포함 된 대형 .zip 패키지를 다운로드하지만 종종 불필요한 의존성을 많이 소개합니다.
2. 스프링 관련 .zip 패키지 만 다운로드하면 종속성이 포함되어 있지 않습니다. 그것들을 사용할 때, 오류 정보에 따라 필요한 다른 종속성을 추가하십시오.
분명히 두 가지 접근 방식은 매우 번거 롭고 Maven의 전이 의존성 메커니즘은이 문제를 잘 해결합니다. 스프링 코어 -4.1.0의 pom.xml을 열면 핵심 부분을 가로 채립니다.
<pectionies> <pectinement> <groupId> Commons-Codec </groupId> <artifactid> commons-codec </artifactid> <버전> 1.9 </version> <copope> compile </scope> <seleption </옵션 </옵션 </옵션> </dependency> <groupid> commons-logging </artifactid> <버전> 1.1.3 </version> <Scope> 컴파일 </scope> </fectionency> ... </fectionements>
예를 들어, 프로젝트 A는 스프링 코어에 의존하고, 스프링 코어는 커먼즈 코덱 및 커먼즈 로깅에 의존하므로 커먼즈 코데 및 커먼즈 로깅은 프로젝트 A의 전이 의존성입니다. Maven은 각 직접 의존성 POM을 구문 분석하고 전이 의존성 형태로 현재 프로젝트에 필요한 간접 종속성을 소개합니다.
전이 의존성 메커니즘을 사용하면 한편으로는 종속성 선언을 크게 단순화하고 용이하게합니다. 반면에, 대부분의 경우, 우리는 프로젝트의 직접적인 종속성이 무엇인지에 대해서만 관심을 가질 필요가 있으며 이러한 직접 의존성에 의해 어떤 전이 종속성이 도입 될지 고려할 필요가 없습니다. 그러나 때로는 전이 의존성에도 문제가 있습니다. 현재, 우리는 전이 의존성이 도입 된 경로를 지워야합니다. 이것을 종속성 중재라고합니다. 의존성 중재의 두 가지 주요 원칙이 있습니다.
1. 현재 가장 가까운 경로가 선호되므로 X (2.0)가 구문 분석되어 사용됩니다.
2. a-> b-> y (1.0), a-> c-> y (2.0), y (1.0) 및 y (2.0)의 의존성 길이는 동일하다. Maven2.0.9에서 시작하여 첫 번째 진술은 우선 순위를 따릅니다. 즉, 가장 높은 순서의 종속성이 선호됩니다.
종속성을 제외합니다
전이 의존성은 프로젝트에 많은 의존성을 암시 적으로 도입하여 프로젝트 종속성 관리를 크게 단순화하지만 때로는이 기능이 문제를 일으킬 수 있습니다. 예를 들어 상황이 있습니다.
현재 프로젝트는 A에 따라 다릅니다. A는 어떤 이유로 다른 클래스 라이브러리의 스냅 샷 버전에 따라 다릅니다. 이 스냅 샷은 현재 프로젝트의 전이 의존성이됩니다. 둘째, 스냅 샷의 불안정성은 현재 프로젝트에 직접적인 영향을 미칩니다. 현재 스냅 샷을 제외해야하며 현재 프로젝트에서 클래스 라이브러리의 공식 릴리스 버전이 선언되었습니다.
종속성을 배제하는 것은 매우 간단합니다. 작문 방법을 살펴 보겠습니다.
<pectionency> <groupId> com.alibaba.rocketmq </groupId> <artifactid> Rocketmq-client </artifactid> <bersion> 3.2.7 </version> <xceplusions> <groupid> apache-lang </groupid> <artifactid> commons-lang </expencives> </explusions> </explusions> </explusions.
여기에서 RocketMQ의 종속성을 도입했지만 RocketMQ의 Apache-Lang에 의존하고 싶지는 않지만 직접 의존성을 도입하고 싶기 때문에 Apache-Lang을 제외했습니다.
여기서 배제를 선언 할 때 GroupId 및 aritifactid 만 필요하며 버전 요소가 필요하지 않다는 점에 유의해야합니다. 이는 종속성 그래프의 종속성을 고유하게 찾기 위해서는 GroupId와 artifactid만이 필요하기 때문입니다. 다시 말해, Maven Parsed 종속성에서는 동일한 GroupID 및 aritifactid를 사용하지만 다른 버전을 가진 두 가지 종속성을 갖는 것은 불가능합니다.
settings.xml
settings.xml은 Maven의 기본 구성입니다. 많은 요소가 있으므로 하나씩 살펴 보겠습니다.
1. 프록시
프록시는 Maven의 프록시를 의미합니다. 글쓰기 방법을 살펴 보겠습니다.
<proxies> <proxy> <id> 선택 사항 </id> <ctive> true </active> <cortocol> http </procecol> <username> proxyuser </username> <passpact> proadypass </password> <host> proxy.host.net </host> 80 </port> <proxyhosts> local.net | some.host.net | </proxy> </proxies>
회사에서 보안 고려 사항을 기반으로 보안 인증 프록시를 사용하여 인터넷에 액세스해야하기 때문에 프록시가 필요합니다. 이 경우 Maven에 대한 HTTP 프록시를 구성하여 외부 저장소에 정상적으로 액세스하여 필수 리소스를 다운로드 할 수 있습니다. 다중 프록시 요소는 프록시에서 구성 할 수 있습니다. 다중 프록시 요소가 선언되면 첫 번째 프록시 활성화가 기본적으로 적용됩니다. Active는 프록시를 활성화하기 위해 충실하며 프로토콜은 사용 된 프록시 프로토콜을 나타냅니다. 물론 가장 중요한 것은 올바른 호스트 이름 (호스트)과 포트 (포트)를 지정하는 것입니다. 프록시 서버에 인증이 필요한 경우 사용자 이름과 비밀번호를 구성하십시오. 비 ProxyHost 요소는 어떤 호스트 이름에 프록시가 필요하지 않은지를 나타냅니다. "|"를 사용할 수 있습니다. 여러 호스트 이름을 분리하고 와일드 카드 "*"도 지원합니다.
2. 저장소
이 저장소는 Maven의 중앙 창고를 나타냅니다. 기본 원격 창고의 구성 요소는 매우 크지 만 항상 우리의 요구를 충족시키지 못하고 다른 중앙 창고가 사용되기 때문입니다. 글쓰기 방법을 살펴 보겠습니다.
<repository> </id> public </id> <name> 지역 개인 넥서스 </name> <url> http://192.168.1.6:8081/nexus/content/groups/public </url> <reeleses> <enabled> true </enable> </릴리스> <snaphots> enabled> enabled> </snapshots> </repository>
다중 저장소를 선언 할 수 있습니다. ID는 독특해야합니다. Maven과 함께 제공되는 중앙 저장소에서 사용한 ID가 중심이라는 특별한주의를 기울이십시오. 다른 저장소 선언 이이 ID를 사용하는 경우 중앙 저장소의 구성이 덮어 씁니다. 릴리스 및 스냅 샷이 더 중요합니다. 전자는 리포지토리에 대한 릴리스 버전 다운로드 지원을 열고, 후자는 스냅 샷 버전 다운로드 지원을 폐쇄하는 것을 의미합니다. 이러한 방식으로 Maven은 저장소로 이동하여 저장소의 스냅 샷 버전을 다운로드하지 않고 리포지토리 릴리스 버전을 다운로드합니다.
3. 서버
대부분의 원격 창고는 인증없이 액세스 할 수 있지만 때로는 보안 요인으로 간주되며 일부 원격 창고에 액세스하기 위해 인증 정보를 제공해야합니다. 보안 고려 사항의 경우, 인증 정보는 일반적으로 settings.xml에만 배치되며 서버는 인증 요소입니다. 구성을 살펴보십시오.
<server> <id> Nexus-Releases </id> <username> 배포 </username> <spection> 배포 </password> </server>
여기의 핵심은 ID입니다. 이 ID는 인증해야 할 repositiry 요소의 ID와 정확히 동일해야합니다. 즉, 공식 ID는 인증 정보와 저장소 구성을 연결합니다.
4. 거울
창고 X가 창고 Y에 저장된 모든 콘텐츠를 제공 할 수 있다면 창고 X는 창고 Y의 미러로 간주 될 수 있습니다. 즉, y에서 얻을 수있는 모든 구성 요소는 X에서 얻을 수 있습니다. 중국. 지리적 위치 요인으로 인해 거울은 종종 중앙 창고보다 더 빠른 서비스를 제공 할 수 있으므로 거울이 사용되는 이유입니다.
미러의 구성을 살펴보십시오.
<mirror> <id> nexus </id> <name> 내부 넥서스 리포지토리 </name> <url> http://192.168.1.6:8081/nexus/content/groups/public </url> <mirrorof>*</mirrorof>
이 예에서 miRorf는 *이며 구성이 모든 중앙 저장소의 거울임을 나타내며 중앙 저장소에 대한 모든 요청이 미러로 전송됩니다. 다른 세 가지 요소 ID, 이름 및 URL은 Mirror Warehouse의 고유 식별자, 이름 및 주소를 나타내는 일반 창고 구성과 다르지 않습니다. 마찬가지로 이미지에 인증이 필요한 경우 id를 기반으로 저장소 인증을 구성 할 수도 있습니다.
읽어 주셔서 감사합니다. 도움이되기를 바랍니다. 이 사이트를 지원 해주셔서 감사합니다!