1. 개요

Maven 의존성을 수동으로 업그레이드하는 것은 특히 자주 릴리스되는 라이브러리가 많은 프로젝트에서 항상 지루한 작업이었습니다.

이 예제에서는 버전 Maven 플러그인을 활용하여 의존성을 최신 상태로 유지하는 방법을 배웁니다 .

무엇보다도 이는 의존성을 자동으로 업그레이드하고 모든 것이 여전히 제대로 작동하는지 테스트하고 결과를 커밋하거나 롤백하는 중 적절한 것을 자동으로 업그레이드하는 지속적 통합 파이프라인을 구현할 때 매우 유용할 수 있습니다.

2. Maven 버전 범위 구문

Maven2 시절에는 개발자가 수동 개입 없이도 아티팩트가 업그레이드되는 버전 범위를 지정할 수 있었습니다.

이 구문은 여전히 ​​유효하며 여러 프로젝트에서 사용되므로 알아둘 가치가 있습니다.

Maven 버전 범위 구문

그럼에도 불구하고 가능한 경우 Versions Maven 플러그인을 사용하는 것을 피해야 합니다. 왜냐하면 외부에서 구체적인 버전을 발전시키면 Maven이 자체적으로 전체 작업을 처리하도록 하는 것보다 확실히 더 많은 제어를 할 수 있기 때문입니다.

2.1. 더 이상 사용되지 않는 구문

Maven2는 또한 결과를 달성하기 위해 LATESTRELEASE 라는 두 가지 특수 메타버전 값을 제공했습니다 .

LATEST  는 가능한 최신 버전을 찾고  RELEASE  는 SNAPSHOT이 아닌 최신 버전을 목표로 합니다.

그들은 실제로 여전히 일반 의존성 해결에 절대적으로  유효합니다  .

그러나 이 레거시 업그레이드 방법으로 인해 CI에 재현성이 필요한 경우 예측할 수 없었습니다. 따라서 플러그인 의존성  해결을 위해 더 이상 사용되지 않습니다 .

3. 버전 메이븐 플러그인

버전 메이븐 플러그인은 현재 버전 관리를 처리 할 수있는 사실상의 표준 방법입니다.

원격 리포지토리 간의 상위 수준 비교에서 SNAPSHOT 버전에 대한 하위 수준 타임스탬프 잠금에 이르기까지 방대한 목표 List을 통해 의존성과 관련된 프로젝트의 모든 측면을 처리할 수 있습니다.

그들 중 많은 것들이 이 예제의 범위를 벗어나지만 업그레이드 프로세스에 도움이 될 것들을 더 자세히 살펴보겠습니다.

3.1. 테스트 케이스

시작하기 전에 테스트 케이스를 정의해 보겠습니다.

  • 하드 코딩된 버전이 포함된 세 가지 릴리스
  • 속성 버전이 있는 하나의 RELEASE 및
  • 하나의 스냅샷
<dependencies>
    <dependency>
        <groupId>commons-io</groupId>
        <artifactId>commons-io</artifactId>
        <version>2.3</version>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-collections4</artifactId>
        <version>4.0</version>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
        <version>3.0</version>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-compress</artifactId>
        <version>${commons-compress-version}</version>
    </dependency>
    <dependency>
        <groupId>commons-beanutils</groupId>
        <artifactId>commons-beanutils</artifactId>
        <version>1.9.1-SNAPSHOT</version>
    </dependency>
</dependencies>

<properties>        
    <commons-compress-version>1.15</commons-compress-version>
</properties>

마지막으로 플러그인을 정의할 때 프로세스에서 아티팩트도 제외해 보겠습니다.

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>2.7</version>
            <configuration>
                <excludes>
                    <exclude>org.apache.commons:commons-collections4</exclude>
                </excludes>
            </configuration>
        </plugin>
    </plugins>
</build>

4. 사용 가능한 업데이트 표시

우선, 단순히 프로젝트를 업데이트할 수 있는지 여부와 방법을 알기 위해 작업에 적합한 도구는 versions:display-dependency-updates입니다 .

mvn versions:display-dependency-updates
mvn 버전:디스플레이 의존성 업데이트

보시다시피 프로세스에는 모든 RELEASE 버전이 포함되었습니다. 구성에서 제외가 검색 프로세스가 아니라 업데이트 프로세스를 참조하기 때문에 여기에는 commons-collections4 도 포함되었습니다  .

대조적으로 SNAPSHOT은 자동 업데이트가 안전하지 않은 개발 버전이기 때문에 무시했습니다.

5. 의존성 업데이트

업데이트를 처음 실행할 때 플러그인은 pom.xml.versionsBackup 이라는 pom.xml 의 백업을 생성합니다 .

모든 반복이 변경되지만 pom.xml 파일을 (를 통해 백업 파일은 원래 사용자가 커밋 할 순간에 프로젝트까지의 상태를 유지합니다 MVN : 커밋 버전 (통하거나 되돌릴) MVN : 되돌리기 버전의 전체 과정).

5.1. SNAPSHOT을 RELEASE로 변환

프로젝트에 SNAPSHOT(아직 많이 개발 중인 버전)이 포함되어 있는 경우가 있습니다.

우리가 사용할 수있는 버전 : 사용-출시, 동시에 그 자료에 우리의 스냅 샷을 변환 할 대응 자료가 게시 된 경우 확인하고 더하기 :

mvn versions:use-releases
mvn 버전:사용 릴리스

5.2. 다음 릴리스로 업데이트

우리가 할 수있는 포트 가장 가까운 버전으로 모든 스냅 샷이 아닌 의존성버전 : 사용 - 다음 - 출시 :

mvn versions:use-next-releases
mvn 버전:use-next-releases

플러그인이 commons-io , commons-lang3 , 그리고 더 이상 SNAPSHOT이 아닌 commons-beanutils 까지 다음 버전으로 업데이트했음을 분명히 알 수 있습니다 .

가장 중요한 것은 무시 c를 ommons - collections4 플러그인 구성에서 제외, 및 공유지 - 압축 버전 번호는 속성을 통해 동적으로 지정된 보유하고 있습니다.

5.3. 최신 릴리스로 업데이트

SNAPSHOT이 아닌 모든 의존성을 최신 릴리스로 업데이트하는 것은 동일한 방식으로 작동하며 목표를 단순히 버전:use-latest-releases로 변경합니다 .

mvn versions:use-latest-releases
mvn 버전:최신 릴리스 사용

6. 원하지 않는 버전 필터링

특정 버전을 무시하려는 경우 외부 파일에서 규칙을 동적으로 로드 하도록 플러그인 구성을 조정할 수 있습니다 .

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>versions-maven-plugin</artifactId>
    <version>2.7</version>
    <configuration>
        <rulesUri>http://www.mycompany.com/maven-version-rules.xml</rulesUri>
    </configuration>
</plugin>

가장 주목할만한 것은 <rulesUri> 도 로컬 파일을 참조할 수 있다는 것입니다.

<rulesUri>file:///home/andrea/maven-version-rules.xml</rulesUri>

6.1. 전역적으로 버전 무시

특정 정규 표현식일치하는 버전을 무시 하도록 규칙 파일을 구성할 수 있습니다 .

<ruleset comparisonMethod="maven"
  xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 
  http://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
    <ignoreVersions>
        <ignoreVersion type="regex">.*-beta</ignoreVersion>
    </ignoreVersions>
</ruleset>

6.2. 규칙별로 버전 무시

마지막으로 요구 사항이 더 구체적인 경우 대신 규칙 집합을 작성할 수 있습니다.

<ruleset comparisonMethod="maven"
  xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 
    http://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
    <rules>
        <rule groupId="com.mycompany.maven" comparisonMethod="maven">
            <ignoreVersions>
                <ignoreVersion type="regex">.*-RELEASE</ignoreVersion>
                <ignoreVersion>2.1.0</ignoreVersion>
            </ignoreVersions>
        </rule>
    </rules>
</ruleset>

7. 결론

안전하고 자동이며 Maven3 호환 방식으로 프로젝트의 의존성을 확인하고 업데이트하는 방법을 살펴보았습니다.

항상 그렇듯이 소스 코드는 GitHub 에서 모든 것을 단계별로 복잡하지 않게 보여 주는 데 도움이 되는 스크립트와 함께 사용할 수 있습니다.

실제로 작동하는지 보려면 프로젝트를 다운로드하고 터미널에서(또는 Windows를 사용하는 경우 Git Bash에서) 실행하기만 하면 됩니다.

./run-the-demo.sh
Generic footer banner