Maven: Bir kitaplık tarafından eklenen bağımlılık nasıl geçersiz kılınır

İşte benim genel problemim:

Projem P, D'nin 1.0.1 sürümüne bağlı olan C'ye bağlı olan B'ye bağlı olan A'ya bağlıdır.

D'nin 1.0.1 sürümünde bir sorun var ve başka bir modülün kullanılmasını zorlamak istiyorum. Doğrudan D'ye bağımlılık eklemediğim için bunu projemin POM'larında nasıl beyan edeceğimi bilmiyorum. D'ye bağımlılığı ilan eden C'dir.

Önemli: Bu durumda, yalnızca sürüm değil, grup ve yapı da değiştirilir. Yani bu sadece bağımlılık versiyonunu geçersiz kılma meselesi değil, daha ziyade bir modülü dışarıda bırakıp diğerini dahil etme meselesi.

Somut durumda, D, 1.0.1'de hata bulunan StAX'tir . Hatadaki notlara göre, "sorunlar stax-api-1.0.1 (maven GroupId = stax) yerine stax-api-1.0-2 (maven GroupId = javax.xml.stream)" ile çözüldü. sadece bunu deniyorum.

Böylece, D = stax: stax-api: jar: 1.0.1 ve C = org.apache.xmlbeans: xmlbeans: jar: 2.3.0

Önemli olması durumunda maven 2.0.9 kullanıyorum.

Mvn bağımlılığının çıktısı: ağaç "

mvn dependency:tree
[..snip..]
[INFO] +- org.apache.poi:poi-ooxml:jar:3.6:compile
[INFO] |  +- org.apache.poi:poi-ooxml-schemas:jar:3.6:compile
[INFO] |  |  +- org.apache.xmlbeans:xmlbeans:jar:2.3.0:compile
[INFO] |  |  |  \- stax:stax-api:jar:1.0.1:compile

Projemin POM'unda aşağıdaki "A" bağımlılığım var:

<dependency>
    <groupId>org.apache.poi</groupId>
    <artifactId>poi</artifactId>
    <version>3.6</version>
</dependency>
<dependency>
    <groupId>org.apache.poi</groupId>
    <artifactId>poi-ooxml</artifactId>
    <version>3.6</version>
</dependency>

Şimdiden teşekkürler.

Mevcut pom'unuzdaki sürümü belirtmeniz yeterlidir. Burada belirtilen sürüm diğerlerini geçersiz kılacaktır.

Bir sürümü zorlamak Bir sürüm
, mevcut POM'da belirli bir sürümle bildirilirse her zaman onurlandırılacaktır - ancak, geçişli bağımlılıkların kullanımına bağlıysa, bunun aşağı akıştaki diğer pomları da etkileyeceği unutulmamalıdır.

Kaynaklar:

• Bağımlılık Arabuluculuğu ve Çatışma Çözümü
• Bağımlılık Mekanizmasına Giriş

Alternatif olarak, istemediğiniz bağımlılığı hariç tutabilirsiniz. STAX, JDK 1.6'ya dahildir, bu nedenle 1.6 kullanıyorsanız, onu tamamen hariç tutabilirsiniz.

Aşağıdaki örneğim sizin için biraz yanlış - iki dışlamadan yalnızca birine ihtiyacınız var, ancak hangisinin olduğundan tam olarak emin değilim. Stax'ın ortalıkta dolaşan başka versiyonları da var, aşağıdaki örneğimde, C & D'yi ithal eden B'yi ithal eden ve her biri (daha fazla geçişli bağımlılıklar aracılığıyla) Stax'ın farklı versiyonlarını içe aktarıp A'yı içe aktarıyordum. Bu nedenle, 'A'ya bağımlılığım nedeniyle, Stax'ın her iki sürümünü de dışladım.

<dependency>
  <groupId>a.group</groupId>
  <artifactId>a.artifact</artifactId>
  <version>a.version</version>
  <exclusions>
    <!--  STAX comes with Java 1.6 -->
    <exclusion>
      <artifactId>stax-api</artifactId>
      <groupId>javax.xml.stream</groupId>
    </exclusion>
    <exclusion>
      <artifactId>stax-api</artifactId>
      <groupId>stax</groupId>
    </exclusion>
  </exclusions>
<dependency>

</dependencies>Kök pom etiketinin içine koyduğunuz şey , kök pom'un tüm alt modülleri tarafından dahil edilecektir. Tüm modülleriniz bu bağımlılığı kullanıyorsa, gitmenin yolu budur.

Ancak, alt modüllerinizin 10'undan sadece 3'ü bir bağımlılık kullanıyorsa, bu bağımlılığın tüm alt modüllerinize dahil edilmesini istemezsiniz. Bu durumda, bağımlılığı </dependencyManagement>. Bu, bağımlılığa ihtiyaç duyan herhangi bir alt modülün onu kendi pom dosyasında bildirmesini sağlar, ancak bu bağımlılığın </dependencyManagement>etiketinizde belirtilenle aynı sürümünü kullanacaklardır .

Ayrıca </dependencyManagement>, geçişli bağımlılıklarda kullanılan sürümü değiştirmek için de kullanabilirsiniz , çünkü en üstteki pom dosyasında bildirilen sürüm, kullanılacak olan sürümdür. Projeniz A, başka bir harici proje C v1.0 içeren harici bir proje B v1.0 içeriyorsa bu yararlı olabilir. Bazen, C v1.0 projesinde v1.1'de düzeltilen bir güvenlik ihlali bulunur, ancak B'nin geliştiricileri projelerini C'nin v1.1'ini kullanacak şekilde güncellemede yavaş davranırlar. Bu durumda, basitçe beyan edebilirsiniz. Projenizin kök pom'unda C v1.1'e bir bağımlılık `` ve her şey iyi olacaktır (B v1.0'ın yine de C v1.1 ile derlenebileceğini varsayarak).

Ayrıca bir üçüncü taraf kitaplığındaki bir bağımlılığı reddetmekte de sorun yaşadım. Dışlama ile scot'un yaklaşımını kullandım ama aynı zamanda pom'a daha yeni sürümle bağımlılığı da ekledim. (Maven 3.3.3 kullandım)

Öyleyse, stAX örneği için şöyle görünecektir:

<dependency>
  <groupId>a.group</groupId>
  <artifactId>a.artifact</artifactId>
  <version>a.version</version>
  <exclusions>
    <!--  STAX comes with Java 1.6 -->
    <exclusion>
      <artifactId>stax-api</artifactId>
      <groupId>javax.xml.stream</groupId>
    </exclusion>
    <exclusion>
      <artifactId>stax-api</artifactId>
      <groupId>stax</groupId>
    </exclusion>
  </exclusions>
<dependency>

<dependency>
    <groupId>javax.xml.stream</groupId>
    <artifactId>stax-api</artifactId>
    <version>1.0-2</version>
</dependency>

Kabul edilen cevap doğru ama iki sentimi de eklemek istiyorum. Bağımlılık olarak B projesi olan bir A projem olduğu bir problemle karşılaştım. Her iki proje de slf4j kullanır, ancak proje A logback kullanırken log4j kullanır. Proje B slf4j 1.6.1'i kullanırken, proje A slf4j 1.7.5'i kullanıyor (zaten dahil edilen logback 1.2.3 bağımlılığı nedeniyle).

Sorun: Proje A, slf4j 1.7.5'te bulunan bir işlevi bulamadı, tutulmanın bağımlılık hiyerarşisi sekmesini kontrol ettikten sonra, derleme sırasında logback'in slf4j 1.7.5 yerine B projesinden slf4j 1.6.1 kullandığını öğrendim. .

A pom projesindeki bağımlılıkların sırasını değiştirerek sorunu çözdüm, proje B girişini logback girişinin altına taşıdığımda maven slf4j 1.7.5 kullanarak projeyi oluşturmaya başladı.

Düzenleme: Proje B bağımlılığı çalışmadan önce slf4j 1.7.5 bağımlılığı ekleniyor.