Maven에게 최신 버전의 종속성을 사용하도록 어떻게 지시합니까?

https://stackoverflow.com/questions/30571

09-06-2019
|

문제

Maven에서 종속성은 일반적으로 다음과 같이 설정됩니다. 라코 디스

이제 자주 릴리스되는 라이브러리로 작업하는 경우 태그를 지속적으로 업데이트하는 것은 다소 성 가실 수 있습니다.Maven에 항상 저장소에서 사용 가능한 최신 버전을 사용하도록 지시하는 방법이 있습니까?

해결책

참고 :

이 답변은 Maven 2에만 적용됩니다! 언급 된 LATEST 및 RELEASE 메타 버전은 가 있습니다. 6 년 전에 "재현 가능한 빌드를 위해" Maven 3에 포함되었습니다. 이 Maven 3 호환 솔루션 을 참조하세요. <시간>

항상 최신 버전을 사용하려는 경우 Maven에는 버전 범위 대신 사용할 수있는 두 개의 키워드가 있습니다. 사용중인 플러그인 / 종속성을 더 이상 제어 할 수 없으므로 이러한 옵션을주의해서 사용해야합니다. <인용구>

플러그인 또는 종속성에 의존하는 경우 LATEST 또는 RELEASE의 버전 값을 사용할 수 있습니다. LATEST는 특정 아티팩트의 최신 릴리스 또는 스냅 샷 버전, 특정 저장소에 가장 최근에 배포 된 아티팩트를 나타냅니다. RELEASE는 저장소에있는 마지막 비 스냅 샷 릴리스를 나타냅니다. 일반적으로 특정 버전의 아티팩트에 의존하는 소프트웨어를 설계하는 것은 모범 사례가 아닙니다. 소프트웨어를 개발하는 경우, 타사 라이브러리의 새 릴리스가 릴리스 될 때 버전 번호를 업데이트 할 필요가 없도록 RELEASE 또는 LATEST를 편리하게 사용할 수 있습니다. 소프트웨어를 릴리스 할 때 항상 프로젝트가 특정 버전에 종속되어 있는지 확인하여 빌드 또는 프로젝트가 제어되지 않는 소프트웨어 릴리스의 영향을받을 가능성을 줄여야합니다. LATEST 및 RELEASE는주의해서 사용하십시오.

Maven 책의 POM 구문 섹션 을 참조하세요. 또는 종속성 버전 범위 에서이 문서를 참조하십시오.

대괄호 ([ 및 ])는 '닫힌'(포함)을 의미합니다.
괄호 (( 및 ))는 '개방'(배타적)을 의미합니다.
다음은 다양한 옵션을 보여주는 예입니다. Maven 저장소에서 com.foo:my-foo에는 다음 메타 데이터가 있습니다. 라코 디스
해당 아티팩트에 대한 종속성이 필요한 경우 다음 옵션이 있습니다 (기타 버전 범위 는 물론 여기에 관련 항목 만 표시하여 지정할 수 있습니다.
정확한 버전 선언 (항상 1.0.1로 확인) : 라코 디스
명시 적 버전 선언 (Maven이 일치하는 버전을 선택할 때 충돌이 발생하지 않는 한 항상 1.0.1로 해결됨) : 라코 디스
모든 1.x의 버전 범위 선언 (현재 1.1.1로 확인) : 라코 디스
개방형 버전 범위 선언 (2.0.0으로 확인) : 라코 디스
버전을 최신 버전으로 선언 (2.0.0으로 확인 됨) (maven 3.x에서 제거됨) 라코 디스
버전을 RELEASE로 선언합니다 (1.1.1로 해결됨) (maven 3.x에서 제거됨) : 라코 디스
기본적으로 자체 배포는 Maven 메타 데이터의 "최신"항목을 업데이트하지만 "release"항목을 업데이트하려면 Maven 슈퍼 POM . "-Prelease-profile"또는 "-DperformRelease= true"로이 작업을 수행 할 수 있습니다. <시간>
어떤 앱이든

Maven이 종속성 버전 (LATEST, RELEASE 및 버전 범위)을 선택할 수 있도록하는 접근 방식은 이후 버전이 다른 동작을 가질 수 있기 때문에 빌드 시간 문제를 열어 둘 수 있습니다 (예 : 종속성 플러그인이 이전에 기본값을 true에서 false로 전환 했음). , 혼란스러운 결과).

따라서 일반적으로 릴리스에서 정확한 버전을 정의하는 것이 좋습니다. 팀의 답변 은 maven-versions-plugin 이 편리한 도구라고 지적합니다. 종속성 버전 업데이트, 특히 버전 : use-latest- 버전 및 버전 : use-latest-releases 목표

다른 팁

이제이 주제가 오래되었다는 것을 알고 있지만 질문과 OP 제공 답변을 읽으면 Maven 버전 플러그인 이 실제로 그의 질문에 대한 더 나은 답변 일 수 있습니다.

특히 다음 목표를 사용할 수 있습니다.

versions : use-latest-versions 는 pom에서 모든 버전을 검색합니다. 최신 버전이고 최신으로 대체 버전.
versions : use-latest-releases 는 모든 non-SNAPSHOT에 대해 pom을 검색합니다. 최신 버전 해제하고 그들을 최신 릴리스 버전
versions : update-properties 는 그들이 대응하도록 프로젝트 사용 가능한 최신 버전 특정 종속성. 이것은 될 수있다 종속성 모음에 유용합니다. 모두 하나의 버전에 잠겨 있어야합니다.
다음과 같은 다른 목표도 제공됩니다.

versions : display-dependency-updates 는 프로젝트의 종속성을 스캔하고 그들에 대한 보고서를 생성 더 새로운 의존성 사용 가능한 버전.
versions : display-plugin-updates 는 프로젝트의 플러그인을 스캔하고 해당 플러그인에 대한 보고서를 생성합니다. 최신 버전을 사용할 수 있습니다.
versions : update-parent 는 프로젝트의 상위 섹션을 업데이트하므로 최신 참조 사용 가능한 버전. 예를 들어 회사 루트 POM을 사용합니다. 필요한 경우 목표가 도움이 될 수 있습니다. 최신을 사용하고 있는지 확인하십시오 회사 루트 POM의 버전입니다.
versions : update-child-modules 는 프로젝트의 자식 모듈이므로 버전은 현재 프로젝트. 예를 들어 또한 애그리 게이터 pom이 있습니다. 프로젝트의 부모 집계 및 하위 및 상위 버전이 동기화되지 않습니다. mojo는 자식 모듈. (참고로 -N 옵션을 사용하여 Maven을 호출하십시오. 이 목표를 실행하려면 프로젝트가 너무 심하게 손상되어 버전 때문에 빌드 할 수 없습니다 불일치).
versions : lock-snapshots 는 모든 -SNAPSHOT에 대한 pom을 검색합니다. 버전을 변경하고 현재 타임 스탬프 버전 -SNAPSHOT, 예 : -20090327.172306-4
versions : unlock-snapshots 는 모든 타임 스탬프에 대해 pom을 검색합니다. 잠긴 스냅 샷 버전 및 교체 -SNAPSHOT을 사용합니다.
versions : resolve-ranges 는 버전 범위를 사용하여 종속성을 찾고 범위를 특정 사용중인 버전입니다.
versions : use-releases 는 pom에서 모든 -SNAPSHOT 버전을 검색합니다. 출시되었으며 대체 해당 릴리스와 함께 버전.
versions : use-next-releases 는 모든 non-SNAPSHOT에 대해 pom을 검색합니다. 최신 버전 해제하고 그들을 다음 릴리스 버전
versions : use-next-versions 는 pom에서 모든 버전을 검색합니다. 최신 버전이고 다음 버전으로 대체합니다.
versions : commit 은 pom.xml.versionsBackup 파일을 제거합니다. 양식 내장 "불쌍한 남자의 절반 SCM ".
versions : revert 는 pom.xml 파일을 pom.xml.versionsBackup 파일. 양식 내장 "불쌍한 남자의 절반 SCM ".
향후 참조를 위해 포함 할 것이라고 생각했습니다.

여기를 참조하십시오.페이지 ( "종속성 버전 범위"섹션).당신이 원하는 것은 라코 디스

이 버전 범위는 Maven2에서 구현됩니다.

다른 사람들과 달리 항상 최신 버전을 원하는 이유가 많이 있다고 생각합니다. 특히 지속적 배포 (때로는 하루에 5 개 정도의 릴리스가 있음)를 수행하고 있고 다중 모듈 프로젝트를 수행하고 싶지 않은 경우.

내가하는 일은 Hudson / Jenkins가 모든 빌드에 대해 다음을 수행하도록하는 것입니다. 라코 디스

즉, 버전 플러그인과 scm 플러그인을 사용하여 종속성을 업데이트 한 다음 소스 제어에 체크인합니다. 예, 내 CI가 SCM 체크인을 수행하도록합니다 (어쨌든 maven 릴리스 플러그인에 대해 수행해야 함).

원하는 내용 만 업데이트하도록 버전 플러그인을 설정하는 것이 좋습니다. 라코 디스

릴리스 플러그인을 사용하여 -SNAPSHOT을 처리하고 -SNAPSHOT의 릴리스 버전이 있는지 확인하는 릴리스를 수행합니다 (중요).

내 작업을 수행하면 모든 스냅 샷 빌드에 대한 최신 버전과 릴리스 빌드에 대한 최신 릴리스 버전을 받게됩니다. 빌드도 재현 가능합니다.

업데이트

이 워크 플로의 세부 사항을 묻는 댓글이 몇 개 있습니다. 더 이상이 방법을 사용하지 않으며 maven 버전 플러그인이 버그가 있고 일반적으로 본질적으로 결함이있는 가장 큰 이유입니다.

버전 플러그인을 실행하여 버전을 조정하기 때문에 pom이 올바르게 실행되기 위해 기존 버전이 모두 존재해야하기 때문에 결함이 있습니다. 즉, 버전 플러그인은 pom에서 참조 된 버전을 찾을 수없는 경우 최신 버전으로 업데이트 할 수 없습니다. 디스크 공간상의 이유로 오래된 버전을 자주 정리하기 때문에 실제로는 다소 짜증이납니다.

정말로 버전을 조정하려면 maven과 별도의 도구가 필요합니다 (따라서 올바르게 실행하기 위해 pom 파일에 의존하지 않아도됩니다). 나는 그런 도구를 Bash라는 낮은 언어로 작성했습니다. 스크립트는 버전 플러그인과 같은 버전을 업데이트하고 pom을 소스 제어로 다시 확인합니다. 또한 mvn 버전 플러그인보다 100 배 더 빠르게 실행됩니다. 안타깝게도 대중 용으로 작성되지 않았지만 사람들이 관심이 있다면 요점이나 github에 넣을 수 있습니다.

우리가하는 일에 대해 일부 의견이 물었을 때 워크 플로로 돌아 가기 :

자신의 젠킨스 작업이있는 자체 저장소에 20 개 정도의 프로젝트가 있습니다.
출시 할 때 Maven 릴리스 플러그인이 사용됩니다. 그 작업 흐름은 플러그인 문서에서 다룹니다. maven 릴리스 플러그인은 일종의 짜증나지만 (나는 친절합니다) 작동합니다. 언젠가이 방법을보다 최적의 방법으로 대체 할 계획입니다.
프로젝트 중 하나가 릴리스되면 젠킨스가 특별한 작업을 실행하면 모든 버전 업데이트 작업을 호출합니다 (젠킨스가 릴리스를 아는 방법은 부분적으로는 메이븐 젠킨스 릴리스 플러그인도 매우 형편 없기 때문에 복잡한 방식입니다).
모든 버전 업데이트 작업은 20 개의 프로젝트를 모두 알고 있습니다. 실제로 모듈 섹션의 모든 프로젝트를 종속성 순서로 특정하는 것은 집계 자 pom입니다. Jenkins는 모든 프로젝트를 최신 버전으로 업데이트 한 다음 poms를 체크인하는 매직 groovy / bash foo를 실행합니다 (다시 모듈 섹션에 따라 종속성 순서대로 수행됨).
각 프로젝트에 대해 pom이 변경된 경우 (일부 종속성의 버전 변경으로 인해) 체크인 한 다음 즉시 젠킨스를 핑하여 해당 프로젝트에 대한 해당 작업을 실행합니다 (이는 빌드 종속성 순서를 유지하기위한 것입니다. SCM 폴 스케줄러의 자비에 따라).
이 시점에서 저는 릴리스 및 자동 버전을 일반 빌드와 별도의 도구로 사용하는 것이 좋은 것이라고 생각합니다.
이제 위에 나열된 문제로 인해 maven이 짜증나다고 생각할 수 있지만 확장 가능한 구문 (일명 XML)을 구문 분석하기 쉬운 선언적 도구가없는 빌드 도구에서는 실제로 상당히 어려울 수 있습니다. .
사실 우리는

d bash / groovy 스크립트를 힌트하는 데 도움이되는 네임 스페이스를 통한 사용자 정의 XML 속성 (예 :이 버전을 업데이트하지 마십시오).

The dependencies syntax is located at the Dependency Version Requirement Specification documentation. Here it is is for completeness:

Dependencies' version element define version requirements, used to compute effective dependency version. Version requirements have the following syntax:

1.0: "Soft" requirement on 1.0 (just a recommendation, if it matches all other ranges for the dependency)

[1.0]: "Hard" requirement on 1.0

(,1.0]: x <= 1.0

[1.2,1.3]: 1.2 <= x <= 1.3

[1.0,2.0): 1.0 <= x < 2.0

[1.5,): x >= 1.5

(,1.0],[1.2,): x <= 1.0 or x >= 1.2; multiple sets are comma-separated

(,1.1),(1.1,): this excludes 1.1 (for example if it is known not to work in combination with this library)

In your case, you could do something like <version>[1.2.3,)</version>

Are you possibly depending on development versions that obviously change a lot during development?

Instead of incrementing the version of development releases, you could just use a snapshot version that you overwrite when necessary, which means you wouldn't have to change the version tag on every minor change. Something like 1.0-SNAPSHOT...

But maybe you are trying to achieve something else ;)

Who ever is using LATEST, please make sure you have -U otherwise the latest snapshot won't be pulled.

mvn -U dependency:copy -Dartifact=com.foo:my-foo:LATEST
// pull the latest snapshot for my-foo from all repositories

By the time this question was posed there were some kinks with version ranges in maven, but these have been resolved in newer versions of maven. This article captures very well how version ranges work and best practices to better understand how maven understands versions: https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN8855

The truth is even in 3.x it still works, surprisingly the projects builds and deploys. But the LATEST/RELEASE keyword causing problems in m2e and eclipse all over the place, ALSO projects depends on the dependency which deployed through the LATEST/RELEASE fail to recognize the version.

It will also causing problem if you are try to define the version as property, and reference it else where.

So the conclusion is use the versions-maven-plugin if you can.

Sometimes you don't want to use version ranges, because it seems that they are "slow" to resolve your dependencies, especially when there is continuous delivery in place and there are tons of versions - mainly during heavy development.

One workaround would be to use the versions-maven-plugin. For example, you can declare a property:

<properties>
    <myname.version>1.1.1</myname.version>
</properties>

and add the versions-maven-plugin to your pom file:

<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>versions-maven-plugin</artifactId>
            <version>2.3</version>
            <configuration>
                <properties>
                    <property>
                        <name>myname.version</name>
                        <dependencies>
                            <dependency>
                                <groupId>group-id</groupId>
                                <artifactId>artifact-id</artifactId>
                                <version>latest</version>
                            </dependency>
                        </dependencies>
                    </property>
                </properties>
            </configuration>
        </plugin>
    </plugins>
</build>

Then, in order to update the dependency, you have to execute the goals:

mvn versions:update-properties validate

If there is a version newer than 1.1.1, it will tell you:

[INFO] Updated ${myname.version} from 1.1.1 to 1.3.2

If you want Maven should use the latest version of a dependency, then you can use Versions Maven Plugin and how to use this plugin, Tim has already given a good answer, follow his answer.

But as a developer, I will not recommend this type of practices. WHY?

answer to why is already given by Pascal Thivent in the comment of the question

I really don't recommend this practice (nor using version ranges) for the sake of build reproducibility. A build that starts to suddenly fail for an unknown reason is way more annoying than updating manually a version number.

I will recommend this type of practice:

<properties>
    <spring.version>3.1.2.RELEASE</spring.version>
</properties>

<dependencies>

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>${spring.version}</version>
    </dependency>

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
        <version>${spring.version}</version>
    </dependency>

</dependencies>

it is easy to maintain and easy to debug. You can update your POM in no time.

MY solution in maven 3.5.4 ,use nexus, in eclipse:

<dependency>
    <groupId>yilin.sheng</groupId>
    <artifactId>webspherecore</artifactId>
    <version>LATEST</version> 
</dependency>

then in eclipse: atl + F5, and choose the force update of snapshots/release

it works for me.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow