Maven  pom.xml과 settings.xml 상세 정보

pom.xml과 settings.xml
pom.xml과 설정.xml은 Maven에서 가장 중요한 두 개의 프로필이라고 할 수 있는데 Maven의 핵심 기능을 결정한다. 비록 이전의 글은 자질구레한pom를 언급한 적이 있지만.xml 및 settings.xml의 내용은 모두 대충 가지고 다녔기 때문에 학습과 연구가 세밀하지 않다. 본고의 목적은 이 두 Maven의 중요한 프로필을 상세하게 연구하는 것이다. 이 두 프로필에서 매우 많은 Maven 화제를 불러일으킬 수 있다.
Maven 좌표
우선 왜 마븐 좌표를 사용해야 하는지 얘기해 봅시다.
Maven 세계는 수량이 매우 큰 부품, 즉 평소에 사용하는jar,war 등 파일을 가지고 있다. Maven이 이 부품들을 위해 좌표 개념을 도입하기 전에 우리는 어떤 방식으로도 이 부품들을 유일하게 표시할 수 없다.따라서 Spring 의존도가 필요하다면 Spring 홈페이지를 찾아라.log4j를 사용해서 의존해야 한다면 아파치 홈페이지에서 찾으세요.또 각 사이트의 풍격이 현저히 다르기 때문에 대량의 시간을 웹 페이지를 검색하고 조회하는 데 썼다.통일된 규범과 법칙이 없으면 일은 자동화할 수 없고, 중복적인 노동은 원래 기계에 맡겨야 한다.
Maven은 이러한 규칙을 정의했다. 세계의 모든 부품은 Maven 좌표의 유일한 표지를 사용할 수 있다. Maven 좌표 요소는 그룹Id,artifactId,version,packaging,classifier를 포함한다. 이제 우리가 정확한 원소 좌표를 제공하면 Maven은 대응하는 부품을 찾을 수 있다.Maven은 어디에서 다운로드할 수 있는지에 대해 중앙 창고의 주소를 내장하고 있습니다."http://repo1.maven.org/maven2"이 중앙 창고는 세계에서 가장 많이 유행하는 개원 프로젝트 부품을 포함하고 있다. Mavne은 필요할 때 그곳에 가서 다운로드할 수 있다. 물론 자신의 중앙 창고 주소를 설정하고 자신의 중앙 창고에 가서 부품을 다운로드할 수 있다.
예를 들어, Spring의 context:

<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-context</artifactId>
  <version>4.2.6.RELEASE</version>
</dependency

부하의 각 요소를 살펴보자.

groupId: 현재 Maven 프로젝트가 속한 실제 프로젝트를 정의합니다.Maven 프로젝트와 실제 프로젝트가 반드시 일대일의 관계가 아니다. 예를 들어 SpringFramework라는 실제 프로젝트에 대응할 수 있는 Maven 프로젝트는 매우 많다. 예를 들어core,context,expression 등이다. 그러므로 그룹 Id는 프로젝트에 속하는 회사나 조직에 대응하지 말아야 한다. 그렇지 않으면artifact는 정의하기 어렵다

artifactId: 실제 프로젝트 중의 Maven 모듈을 정의합니다. 추천하는 방법은 실제 프로젝트 이름을artifactId의 접두사로 사용하면 실제 부품을 찾기에 편리합니다

version: Maven 프로젝트의 현재 버전을 정의합니다. 예를 들어 위의spring-context는 4.2.6입니다. RELEASE는 정식 버전을 표시합니다

패킹: 마븐 프로젝트의 포장 방식을 정의합니다. 이것은 필수적인 것이 아닙니다. 열거하지 않았습니다. 기본적으로jar의 포장 방식을 정의하지 않습니다

classifier: 구성 요소 출력을 정의하는 데 도움을 주는 일부 부속 구성 요소, 예를 들어 xx-javadoc.jar、xxx-sources.jar, 부속 부품은 주 부품과 대응합니다. 이 항목은 직접 정의할 수 없습니다.

Maven 좌표의 개념은 대체적으로 이렇다. Maven 좌표를 이해하는 것은 Maven을 이해하는 데 매우 중요한 단계이다.
전달적 의존
Spring을 예로 들면 전달적 의존이 무엇입니까?Spring을 사용할 때 다른 소스 기반 라이브러리에 의존하는 두 가지 방법이 있습니다.
1. 큰 것을 다운로드합니다.zip 패키지에는 모든 스프링의jar가 포함되어 있지만, 이렇게 하면 종종 불필요한 의존을 많이 끌어들인다
2. 스프링과 관련된 것만 다운로드합니다.zip 패키지, 의존을 포함하지 않습니다. 실제로 사용할 때 오류 정보에 따라 필요한 다른 의존을 추가합니다.
분명히 이 두 가지 방법은 모두 매우 번거롭다. Maven의 전달적 의존 메커니즘이 이 문제를 잘 해결했다.스프링-코어-4.1.0을 엽니다.RELEASE의pom.xml, 관건적인 부분을 캡처합니다.

<dependencies>
  <dependency>
   <groupId>commons-codec</groupId>
   <artifactId>commons-codec</artifactId>
   <version>1.9</version>
   <scope>compile</scope>
   <optional>true</optional>
  </dependency>
  <dependency>
   <groupId>commons-logging</groupId>
   <artifactId>commons-logging</artifactId>
   <version>1.1.3</version>
   <scope>compile</scope>
  </dependency>
  ...
</dependencies>

예를 들어 A 프로젝트는spring-core에 의존하고spring-core는commons-codec와commons-logging에 의존한다. 그러면commons-codec와commons-logging은 A 프로젝트의 전달적 의존이다.전달적 의존 메커니즘이 있어spring-core를 사용할 때 무엇을 의존했는지 고려할 필요도 없고 불필요한 의존을 도입할 걱정도 없다. Maven은 각 직접 의존의 POM을 분석하고 필요한 간접 의존을 전달적 의존의 형식으로 현재 프로젝트에 도입한다.
전달적 의존 메커니즘이 생기면서 한편으로는 의존 성명을 크게 간소화하고 편리하게 할 수 있다. 다른 한편으로는 대부분의 상황에서 우리는 프로젝트의 직접적인 의존이 무엇인지에 관심을 가져야 한다. 이런 직접적인 의존이 어떤 전달적 의존을 도입할지 고려할 필요가 없다. 그러나 때때로 전달적 의존도 문제가 있을 수 있다. 이때 우리는 이 전달적 의존이 어느 경로에서 도입되었는지 제거해야 한다. 이를 의존 조정이라고 한다.조정에 의존하는 데는 주로 두 가지 원칙이 있다.
1, A->B->C->X(1.0), A->D->X(2.0), 두 의존 경로에 두 가지 버전의 X가 있습니다. 이 경우 가장 가까운 경로가 우선이기 때문에 X(2.0)가 사용됩니다.
2, A->B->Y(1.0), A->C->Y(2.0), Y(1.0)와 Y(2.0)의 의존 길이는 같다. Maven2.0.9부터 시작하여 제1성명자 우선, 즉 순서가 가장 앞에 있는 의존 우선을 따른다.
의존을 배제하다
전달적 의존은 프로젝트에 은밀하게 많은 의존을 도입하는데 이것은 프로젝트 의존의 관리를 크게 간소화시켰지만 때때로 이런 특성도 문제를 가져올 수 있다.예를 들어 다음과 같은 경우가 있습니다.
현재 프로젝트는 A에 의존하고 A는 어떤 이유로 다른 라이브러리의 SNAPSHOT 버전에 의존한다. 그러면 이 SNAPSHOT은 현재 프로젝트의 전달적 의존이 되고 이 SNAPSHOT의 불안정성은 현재 프로젝트에 직접적인 영향을 줄 것이다. 이때 이 SNAPSHOT을 배제하고 현재 프로젝트에서 이 라이브러리의 정식으로 발표된 버전을 성명해야 한다.
의존을 배제하는 것은 간단합니다. 쓰기 방법을 보십시오.

<dependency>
  <groupId>com.alibaba.rocketmq</groupId>
  <artifactId>rocketmq-client</artifactId>
  <version>3.2.7</version>
  <exclusions>
    <exclusion>
      <groupId>apache-lang</groupId>
      <artifactId>commons-lang</artifactId>
    </exclusion>
  </exclusions>
</dependency>

여기에서 나는 rocketmq의 의존을 도입했지만, 나는 rocketmq 안의 아파치-lang에 의존하고 싶지 않고, 스스로 의존을 도입하고 싶어서 아파치-lang을 배제했다.
여기서 주의해야 할 것은exclusion을 설명할 때groupId와artifactId만 있으면 되고version 요소가 필요하지 않다는 것이다. 이것은 그룹Id와artifactId만 있으면 유일하게 의존도에 의존할 수 있기 때문이다.다시 말하면 Maven 해석 후의 의존 중groupId와artifactId는 같지만version은 다른 두 의존이 나타날 수 없다.
 settings.xml
settings.xml에는 Maven의 기본 설정이 있습니다. 요소가 비교적 많습니다. 하나하나 살펴보겠습니다.
1、proxy
proxy는 Maven의 에이전트를 나타냅니다.

<proxies>
  <proxy>
   <id>optional</id>
   <active>true</active>
   <protocol>http</protocol>
   <username>proxyuser</username>
   <password>proxypass</password>
   <host>proxy.host.net</host>
   <port>80</port>
   <nonProxyHosts>local.net|some.host.com</nonProxyHosts>
  </proxy>
</proxies>

프록시가 필요한 것은 당신이 있는 회사가 안전 요소를 고려하여 안전 인증을 통과한 에이전트를 사용하여 인터넷에 접근하도록 요구하는 경우가 많기 때문이다.이 경우 Maven을 위해 HTTP 에이전트를 설정해야 외부 창고에 정상적으로 접근하여 필요한 자원을 다운로드할 수 있습니다.proxies에서 여러 개의 proxy 요소를 설정할 수 있습니다. 여러 개의 proxy 요소를 설명하면 기본적으로 첫 번째 활성화된 proxy가 적용됩니다.active는true로 이 프록시를 활성화합니다. 프로토콜은 사용하는 프록시 프로토콜을 표시합니다. 물론 가장 중요한 것은 정확한 호스트 이름(host)과 포트(port)를 지정하는 것입니다. 프록시 서버에서 인증이 필요하면username과password를 설정하고, nonProxyHost 요소는 프록시가 필요하지 않은 호스트 이름을 지정하는 것입니다.'|'로 여러 호스트 이름을 구분할 수 있고, 어댑터'*'도 지원합니다.
2、repository
repository는 Maven의 중앙 창고를 표시합니다. 기본 원격 창고의 부품이 매우 방대하지만 어쨌든 우리의 수요를 만족시키지 못할 때가 있습니다. 이럴 때 다른 중앙 창고를 사용해야 합니다.쓰기 방법:

<repository>
  <id>public</id>
  <name>local private nexus</name>
  <url>http://192.168.1.6:8081/nexus/content/groups/public</url>
  <releases>
    <enabled>true</enabled>
  </releases>
  <snapshots>
    <enabled>false</enabled>
  </snapshots>
</repository>

여러 개의 Repository를 설명할 수 있습니다.id는 유일해야 합니다. 특히 Maven이 가지고 있는 중앙 창고에서 사용하는 id는central입니다. 다른 창고에서도 이 id를 사용하면 중앙 창고의 설정을 덮어씁니다.releases와 snapshots는 비교적 중요하다. 전자는 창고를 여는 발표 버전 다운로드 지원을 표시하고, 후자는 창고를 닫는 스냅샷 버전 다운로드 지원을 표시한다. 그러면 Maven은 창고에 가서 발표 버전 부품을 다운로드하고 스냅샷 버전 부품을 다운로드하지 않는다.
3、server
대부분의 원격 창고는 인증하지 않아도 방문할 수 있지만 때때로 안전 요소에 대한 고려가 있기 때문에 인증 정보를 제공해야 일부 원격 창고에 접근할 수 있고 안전에 대한 고려가 있기 때문에 인증 정보는 일반적으로settings에만 놓여 있다.xml에서 서버는 인증 요소입니다.구성 보기:

<server>
  <id>nexus-releases</id>
  <username>deployment</username>
  <password>deployment</password>
</server>

여기서 관건은 id입니다. 이 id는 인증이 필요한repositiry 요소의 id와 완전히 일치해야 합니다. 다시 말하면 이 id는 인증 정보와 창고 설정을 연결합니다.
4、mirror
창고 X가 창고 Y에 저장된 모든 내용을 제공할 수 있다면 창고 X는 창고 Y의 거울 (mirror) 이라고 생각할 수 있다. 다시 말하면 Y에서 얻을 수 있는 모든 구성 요소는 X에서 얻을 수 있다.예를 들어, "http://maven.net.cn/content/groups/public/"중앙창고예요".http://repo1.maven.org/maven2/"중국의 거울은 지리적 위치 때문에 중앙 창고보다 더 빠른 서비스를 제공할 수 있는데 이것이 바로 미러를 사용해야 하는 이유입니다.
mirror 구성 보기:

<mirror>
  <id>nexus</id>
  <name>internal nexus repository</name>
  <url>http://192.168.1.6:8081/nexus/content/groups/public</url>
  <mirrorOf>*</mirrorOf>
</mirror>

이 예에서mirrof는 *로 이 설정은 모든 중앙 창고의 거울이며, 중앙 창고에 대한 요청은 이 거울로 넘어간다.다른 세 가지 요소 id,name,url은 일반 창고 설정과 다름없습니다. 이 창고의 유일한 식별자, 이름, 주소를 나타냅니다.유사하게, 이 거울이 인증을 필요로 한다면, 이 id를 기반으로 창고 인증을 설정할 수도 있습니다.
읽어주셔서 감사합니다. 여러분에게 도움이 되었으면 좋겠습니다. 본 사이트에 대한 지지에 감사드립니다!