Mengapa Maven mengunduh maven-metadata.xml setiap saat?


116

Di bawah ini adalah error yang biasa saya dapatkan ketika koneksi internet saya lemas ketika mencoba membangun aplikasi web dengan maven.

Pertanyaan saya adalah, kenapa maven selalu harus mendownload setiap kali aplikasi yang sama telah dibuat sebelumnya.

Apa yang salah dalam konfigurasi saya yang membuat maven mengunduh setiap saat?

Di bawah ini adalah kesalahan yang saya dapatkan ketika saya mencoba membangun secara offline:

[INFO] ------------------------------------------------------------------------
[INFO] Building mywebapp 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: https://raw.github.com/pagecrumb/mungo/mvn-repo/com/pagecrumb/mungo/0.0.1-SNAPSHOT/maven-metadata.xml

[WARNING] Could not transfer metadata com.mywebapp:mungo:0.0.1-SNAPSHOT/maven-metadata.xml 
from/to mungo-mvn-repo (https://raw.github.com/pagecrumb/mungo/mvn-repo/): raw.github.com
[INFO] 
[INFO] --- maven-war-plugin:2.1.1:war (default-cli) @ mywebapp ---
[INFO] Packaging webapp
[INFO] Assembling webapp [mywebapp] in [D:\workspace\web\target\mywebapp-1.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources [D:\workspace\web\src\main\webapp]
[INFO] Webapp assembled in [1237 msecs]
[INFO] Building war: D:\workspace\web\target\mywebapp-1.0-SNAPSHOT.war
[WARNING] Warning: selected war files include a WEB-INF/web.xml which will be ignored 
(webxml attribute is missing from war task, 
or ignoreWebxml attribute is specified as 'true')
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building com.mywebapp [com.mywebapp] 0.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
Downloading: http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-release-plugin/2.1/maven-release-plugin-2.1.pom

[WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-release-plugin:2.1: Plugin org.apache.maven.plugins:maven-release-plugin:2.1 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-release-plugin:jar:2.1
Downloading: http://download.java.net/maven/2/org/apache/maven/plugins/maven-metadata.xml
Downloading: http://download.java.net/maven/2/org/codehaus/mojo/maven-metadata.xml

397/397 B   

Downloaded: http://download.java.net/maven/2/org/codehaus/mojo/maven-metadata.xml (397 B at 0.0 KB/sec)
[WARNING] Failure to transfer org.apache.maven.plugins:maven-war-plugin/maven-metadata.xml from http://download.java.net/maven/2 was cached in the local repository, resolution will not be reattempted until the update interval of maven2-repository.dev.java.net has elapsed or updates are forced. Original error: Could not transfer metadata org.apache.maven.plugins:maven-war-plugin/maven-metadata.xml from/to maven2-repository.dev.java.net (http://download.java.net/maven/2): download.java.net
[INFO] 
[INFO] --- maven-war-plugin:2.3:war (default-cli) @ mywebapp-build ---
[INFO] Packaging webapp
[INFO] Assembling webapp [mywebapp-build] in [D:\workspace\target\mywebapp-build-0.0.1-SNAPSHOT]
[INFO] Processing war project
[INFO] Webapp assembled in [15 msecs]
[INFO] Building war: D:\workspace\target\mywebapp-build-0.0.1-SNAPSHOT.war
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] mywebapp ..................................... SUCCESS [27.999s]
[INFO] com.mywebapp [com.mywebapp] ..................... FAILURE [1:00.406s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:41.409s
[INFO] Finished at: Tue May 07 22:13:38 SGT 2013
[INFO] Final Memory: 11M/28M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.3:war 
(default-cli) on project mywebapp-build: Error assembling WAR: webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode)

2
Akses ke metadata jika SNAPSHOT diperlukan untuk memberi tahu Maven tentang SNAPSHOT yang baru dibuat, dll.
khmarbaise

7
Saya tidak tahu mengapa tetapi Anda dapat menghindari ini dengan menggunakan opsi -o sepertimvn clean install -o
semut

Sebenarnya, kesalahan di mana build gagal adalah "Error assembling WAR: atribut webxml diperlukan (atau WEB-INF / web.xml yang sudah ada sebelumnya jika dijalankan dalam mode update)". Jadi, Anda harus memperbaikinya. Saya tidak bisa membayangkannya terkait dengan koneksi internet Anda. Peringatan resolusi ketergantungan hanya itu: peringatan. Mereka bukanlah penyebab utama kegagalan build Anda.
Frans

Mungkin Anda dapat memperjelas pertanyaan Anda karena Anda sepertinya memiliki dua pertanyaan: 1) Mengapa bangunan saya gagal? 2) Mengapa maven mencoba mengunduh metadata? Jawaban pengguna944849 sangat berguna untuk menjawab 2). Jika itu menjawab pertanyaan Anda, Anda harus menerimanya.
Frans

Pembaruan metadata snapshot dapat dihindari menggunakan -nsu, --no-snapshot-updatesopsi denganmvn
Janaka Bandara

Jawaban:


127

Cari elemen di settings.xml(atau, mungkin induk proyek atau induk perusahaan Anda) <repositories>. Ini akan terlihat seperti di bawah ini.

<repositories>
    <repository>
        <id>central</id>
        <url>http://gotoNexus</url>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>always</updatePolicy>
        </snapshots>
        <releases>
            <enabled>true</enabled>
            <updatePolicy>daily</updatePolicy>
        </releases>
    </repository>
</repositories>

Perhatikan <updatePolicy>elemennya. Contoh ini memberi tahu Maven untuk menghubungi repo jarak jauh (Nexus dalam kasus saya, Maven Central jika Anda tidak menggunakan repo jarak jauh Anda sendiri) kapan saja Maven perlu mengambil artefak snapshot selama pembuatan, memeriksa untuk melihat apakah ada salinan yang lebih baru. Metadata diperlukan untuk ini. Jika ada salinan yang lebih baru, Maven mengunduhnya ke repo lokal Anda.

Dalam contoh, untuk rilis, kebijakannya dailyakan diperiksa selama pembuatan pertama Anda hari itu. neverjuga merupakan opsi yang valid, seperti yang dijelaskan dalam dokumen pengaturan Maven .

Plugin diselesaikan secara terpisah. Anda mungkin memiliki repositori yang dikonfigurasi untuk itu juga, dengan kebijakan pembaruan berbeda jika diinginkan.

<pluginRepositories>
    <pluginRepository>
        <id>central</id>
        <url>http://gotoNexus</url>
        <snapshots>
            <enabled>true</enabled>
            <updatePolicy>daily</updatePolicy>
        </snapshots>
        <releases>
            <enabled>true</enabled>
            <updatePolicy>never</updatePolicy>
        </releases>
    </pluginRepository>
</pluginRepositories>

Orang lain menyebutkan -oopsi tersebut. Jika Anda menggunakannya, Maven berjalan dalam mode "offline". Ia tahu itu hanya memiliki repo lokal, dan itu tidak akan menghubungi repo jarak jauh untuk menyegarkan artefak tidak peduli kebijakan pembaruan apa yang Anda gunakan.


2
Pertanyaannya adalah: mengapa tidak selalu "tidak pernah" (yang menurut saya harus begitu)? Mengapa Anda perlu pembaruan setiap hari atau selalu?
Leon

@Leon Selama siklus pengembangan menengah, proyek Anda mungkin memiliki dependensi '-SNAPSHOT' di mana Anda mungkin ingin selalu memilih versi terbaru yang dibangun - setidaknya, pada sistem CI yang mungkin Anda inginkan, pengembang mungkin memiliki preferensi yang berbeda - perdagangan membangun stabilitas vs mendapatkan perubahan terbaru. Apa yang dokumen maven (secara khas, sayangnya) gagal untuk menjelaskan adalah nilai default untuk ini jika tidak ada yang diatur.
Ed Randall

1
Praktik terbaiknya adalah begitu artefak dirilis tidak pernah berubah, jadi <updatePolicy> never </updatePolicy> harus sesuai untuk mereka.
Ed Randall

Tetapi bagaimana jika Anda memperbarui dependensi POM Anda ke rilis baru? Apakah itu tidak akan pernah diperbarui?
Philip Rego

1
@PhilipRego - updatePolicy berlaku per artefak. Jika Anda mengubah nomor versi atau ID grup / artefak, itu adalah artefak yang berbeda. Jika updatePolicy adalah 'never' maka artefak akan diunduh satu kali, kecuali penyegaran dipaksa dengan -Uatau artefak dihapus dari repo lokal dan karenanya perlu diunduh ulang.
pengguna944849

31

Mungkin menggunakan bendera -o,--offline "Work offline"untuk mencegahnya.

Seperti ini:

maven compile -o


Saya yakin ini adalah jawaban yang benar, karena Anda cukup memanggil perintah ini saat koneksi internet Anda lemah. Dan ini yang ditanyakan ...
Jadi S

13

Saya kira karena Anda tidak menentukan versi plugin sehingga memicu unduhan metadata terkait untuk mendapatkan yang terakhir.

Jika tidak, apakah Anda mencoba memaksa penggunaan repo lokal menggunakan -o?


Jadi, bagaimana Anda menentukan versi plugin? Saya yakin saya telah menetapkan versi di POM ... dapatkah Anda lebih spesifik?
quark

nah jika Anda memiliki versionelemen di dalam pluginelemen maka Anda memang telah mengkonfigurasinya, jika demikian saya kehabisan ide ... Semoga berhasil
Gab

dalam kasus saya versinya adalah kisaran [12.1 12.2) dan cache metadata disetel ke 24 jam sehingga akan memeriksa versi yang lebih baru pada pembuatan pertama setiap hari
mzzzzb

Bagaimana dengan plugin default? seperti maven-surefire-common, yang belum saya sebutkan?
yegeniy

versi mereka diperbaiki untuk rilis maven tertentu tetapi Anda dapat memaksakan yang berbeda menggunakan pluginManagementbagian
Gab

0

Saya belum mempelajarinya, ketika Maven melakukan pencarian mana, tetapi untuk mendapatkan build yang stabil dan dapat direproduksi, saya sangat menyarankan untuk tidak mengakses Maven Respositories secara langsung tetapi untuk menggunakan Maven Repository Manager seperti Nexus.

Berikut adalah tutorial cara menyiapkan file pengaturan Anda:

http://books.sonatype.com/nexus-book/reference/maven-sect-single-group.html

http://maven.apache.org/repository-management.html


@acdcjunior seperti yang saya katakan, saya belum mempelajarinya. Tetapi menggunakan Manajer Repositori Maven lokal akan menyelesaikan sebagian besar masalah ini juga (jika Maven memeriksa metadata, ia hanya akan mengakses Manajer Repositori Maven Anda)
Puce

1
IMHO manajer repo hanya berguna di dalam organisasi untuk menghindari pengunduhan yang berlebihan dan terutama untuk menyebarkan artefak khusus untuk organisasi ini (seperti pom induk dan modul internal). Kalau tidak, mengapa menambahkan cermin tambahan karena Anda sudah memiliki cermin lokal?
Gab

@ Puce Saya tidak melihat bagaimana itu akan menyelesaikan masalah. Jika Anda sama sekali tidak ingin maven memeriksa metadata di seluruh jaringan, tidak masalah jika ia memeriksa dari internet atau dari manajer repo intranet.
eis

@eis itu akan membantu jika "koneksi internet lemah" atau jika salah satu server repositori saat ini tidak tersedia, karena Anda hanya mengakses manajer repositori maven di LAN Anda.
Puce

@Gap sementara manajer repo sangat berguna dalam organisasi karena alasan yang Anda sebutkan, manajer repo juga penting untuk mendapatkan build yang stabil dan dapat direproduksi, yang biasanya saya tuju meskipun saat ini saya satu-satunya pengembang di proyek tersebut. Ini memastikan bahwa saya dapat menghapus repo lokal saya dan masih dapat mereproduksi semua build dan bahwa pengembang lain dapat dengan mudah bergabung dengan proyek. Saya menjamin ini dengan Jenkins, yang terkadang juga berjalan secara lokal, mengakses manajer repo juga dan juga membantu merilis proyek saya -> 2 pengguna mengakses manajer repo: Jenkins dan saya sendiri
Puce

0

Maven melakukan ini karena ketergantungan Anda ada dalam versi SNAPSHOT dan maven tidak memiliki cara untuk mendeteksi perubahan apa pun yang dibuat pada versi snapshot tersebut di repositori. Lepaskan artefak Anda dan ubah versi di pom.xml ke versi tersebut dan maven tidak akan lagi mengambil file metadata.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.