Maven gagal menemukan artefak lokal


107

Kadang-kadang maven mengeluh bahwa ketergantungan tertentu, yang dibangun dan dipaketkan secara lokal, tidak dapat ditemukan di repositori lokal saat membangun proyek lain yang memilikinya sebagai ketergantungan. Kami mendapatkan kesalahan seperti:

Gagal menjalankan tujuan pada proyek X: Tidak dapat menyelesaikan ketergantungan untuk proyek X: Kegagalan menemukan Y di [gudang archiva] telah di-cache di repositori lokal, resolusi tidak akan dicoba lagi hingga interval pembaruan internal telah berlalu atau pembaruan dipaksakan - >

Di mana X adalah proyek yang sedang dibangun, dan Y adalah artefak yang seharusnya hilang. Jika Anda melihat di repositori lokal, artefaknya ada di sana. Artefak ini tidak pernah diinstal di repositori archiva kami, jadi masalahnya hanya berbasis di repositori lokal.

Kami telah mencoba berbagai profil di settings.xml, dan tentu saja "mvn -U". Tidak ada gunanya, juga tidak seharusnya karena artefak ini tidak pernah melangkah lebih jauh dari repositori lokal.

Hanya dua hal yang tampaknya berhasil adalah menunggu dalam waktu yang sangat lama sampai maven cerdas, atau untuk menghapus repositori lokal sepenuhnya. Agaknya opsi menunggu terkait dengan interval pembaruan yang disebutkan di atas.

Kami telah mengalami masalah ini dengan maven 3.0.2 dan 3.0.3. Kami menggunakan Archiva 1.0.3 (tetapi sekali lagi ini seharusnya tidak menjadi faktor). Bantuan apa pun akan sangat dihargai.


1
Apakah Maven mencatat sesuatu saat atau sebelum "menunggu?" Yaitu mencoba menyambung ke repositori yang tidak dapat dijangkau? Juga, apakah artefak bermasalah "-SNAPSHOT"?
noahlz

Maven tidak mencatat apa pun selain kesalahan yang saya sebutkan di atas. Dan ya, ini adalah ketergantungan snapshot.
pengguna1686620


1
Sudahkah Anda menginstal paket build sebelum mencoba membangun proyek kedua?
khmarbaise

3
Saya suka bagaimana pesan kesalahan dijalankan, bukan kalimat yang benar secara tata bahasa. Dengan cara ini, kami tidak tahu pasti apakah Y tidak dapat ditemukan atau Y di-cache secara lokal, atau keduanya. Bagaimanapun, saya memiliki masalah yang sama. Saya dapat menyelesaikannya dengan opsi -U karena ketergantungan saya ada di repo internal perusahaan saya. Mengapa artefak yang Anda butuhkan tidak disebarkan ke penyimpanan internal perusahaan Anda?
jyoungdev

Jawaban:


77

Repo lokal Maven melacak tempat asal artefak menggunakan file bernama "_maven.repositories" di direktori artefak. Setelah menghapusnya, build tersebut berfungsi. Jawaban ini memperbaiki masalah saya.


26
Bagi saya itu adalah file bernama "_remote.repositories". Saya menghapusnya dan berhasil! Terima kasih atas triknya!
perbellinio

2
Thx file bernama _remote.repositories juga ada. itu terjadi pada saya ketika nexus kami berhenti memiliki koneksi jaringan sehingga tidak dapat memperoleh dependensi
cabaji99

1
Solusi yang diberikan berhasil. Namun, saya tertarik dengan mengapa masalah ini bisa terjadi. Adakah yang bisa memberi saya penjelasan singkat? Apakah saya harus melakukan sesuatu yang berbeda?
Janothan

Jika Anda ingin melewati pemeriksaan asal ini sekali (tanpa menghapus metafile), coba teruskan aether.enhancedLocalRepository.trackingFilename=some_dummy_file_nameke proses resolusi ketergantungan; cara termudah adalah dengan menambahkan properti sistem -D ke perintah pemanggilan.
Janaka Bandara

@Janothan IMO link di jawaban memberikan penjelasan yang cukup bagus :)
Janaka Bandara

40

Karena opsi di sini tidak berhasil untuk saya, saya membagikan cara saya menyelesaikannya:

Proyek saya memiliki proyek induk (dengan pom.xml sendiri) yang memiliki banyak modul anak, salah satunya (A) memiliki ketergantungan ke anak lain (B). Ketika saya mencoba mvn packagedi A, itu tidak berhasil karena B tidak dapat diselesaikan.

Mengeksekusi mvn install di direktori induk melakukan pekerjaan itu. Setelah itu, saya bisa melakukan mvn packagedi dalam A dan baru kemudian bisa menemukan B.


3
TERIMA KASIH! ini membuatku gila. mvn clean package jboss-as: deploy berfungsi ketika saya mengeksekusi pada satu baris, tetapi tidak ketika saya melakukannya secara terpisah.
PMorganCA

18

Bahkan dalam mode offline, maven akan memeriksa repositori jarak jauh jika ada penanda _remote.repositories untuk ketergantungan tersebut. Jika Anda perlu mengoperasikan dalam mode offline, Anda mungkin perlu menghapus file-file ini.

Perintah shell sederhana di bawah ini menghapus file penanda ini. Ini aman dilakukan jika Anda hanya menggunakan mode offline untuk mesin. Saya TIDAK akan melakukan ini pada mesin yang perlu menarik file dari web.

Saya telah menggunakan strategi ini pada server build yang terputus dari web. Kami harus mentransfer repositori ke sana, menghapus file penanda dan kemudian berjalan dalam mode offline.

Di Linux / Unix Anda dapat menghapus file penanda repositori jarak jauh dengan cara ini:

cd ~/.m2
find . -name "_remote.repositories" -type f -delete

1
Solusi ini berhasil untuk saya, untuk ketergantungan yang saya salin dari komputer lain yang tidak tersedia di repositori pusat. Perintah itu melewatkan beberapa karakter. Ini perintah lengkapnya: temukan. -name "_remote.repositories" -type -f -delete
Hans Deragon

2
Atau, alih-alih menghapus, Anda seharusnya bisa "menyesatkan" Maven untuk tidak melihat _remote.repositoriesfile dengan meneruskan -Daether.enhancedLocalRepository.trackingFilename=some_dummy_file_nameke proses. (Tidak mencoba pada build Maven yang sebenarnya, tetapi berfungsi saat memanggil Maven secara terprogram; jadi yang pertama juga harus berfungsi)
Janaka Bandara

1
Saya melakukan ini untuk menemukan dan menghapus dependensi (toples) tertentu yang tidak ditemukan oleh Maven, karena mereka terdaftar dan dapat dikelola ke (<10). Ini karena kesalahan konfigurasi yang menunjuk ke Nexus jarak jauh yang saat ini tidak tersedia (seperti yang saya mengerti ..). Jadi sebenarnya tidak perlu menyapu semua repo untuk dihapus. Bagaimanapun solusi ini menyelamatkan hari itu. Ini bekerja untuk saya.
Diego1974

9

Ketika ini terjadi pada saya, itu karena saya secara membabi buta menyalin settings.xml saya dari template dan masih memiliki <localRepository/>elemen kosong . Ini berarti tidak ada repositori lokal yang digunakan saat menyelesaikan dependensi (meskipun artefak yang Anda instal masih diletakkan di lokasi default). Ketika saya menggantinya dengan <localRepository>${user.home}\.m2\repository</localRepository>itu mulai bekerja.

Untuk * nix <localRepository>${user.home}/.m2/repository</localRepository>, saya kira.


6
$ {user.home} \. m2 \ repository adalah defaultnya sehingga menghapus tag kosong akan bekerja sama.
Luis Muñoz

9

Maven ingat ketika tidak menemukan sesuatu. Kuncinya adalah "resolusi tidak akan dicoba lagi sampai interval pembaruan internal telah berlalu atau pembaruan dipaksa ->"

Solusi cepatnya adalah menghapus subdirektori "repositori" lokal Anda untuk artefak masalah - dengan asumsi Anda telah memperbaiki masalah dengannya. :)

mvn -U akan memaksa pembaruan dari repositori jarak jauh - sekali lagi, dengan asumsi Anda sekarang telah mengisi jarak jauh dengan artefak tersebut.


2

Tangkap semuanya. Ketika solusi yang disebutkan di sini tidak berfungsi (terjadi dalam kasus saya), cukup hapus semua konten dari folder / direktori '.m2', dan lakukan mvn clean install.


2

Jika Anda telah <repositories/>mendefinisikan di pom.xml Anda ternyata repositori lokal Anda diabaikan.


1

Bahkan saya menghadapi masalah ini dan menyelesaikannya dengan 2 cara:

1) Di IDE Anda pilih proyek dan bersihkan semua proyek kemudian instal semua dependensi maven dengan mengklik kanan pada proyek -> buka maven dan Perbarui dependensi proyek pilih semua proyek sekaligus untuk menginstalnya. Setelah ini selesai, jalankan proyek tertentu

2) Lain Apa yang dapat Anda lakukan adalah cek di pom.xml untuk dependensi yang Anda mendapatkan kesalahan dan "mvn clean install" mereka bergantung proyek pertama dan dependensi menginstal maven dari proyek saat di mana Anda menghadapi masalah. Dengan ini dependensi dari proyek lokal akan dibangun dan jars akan dibuat.


0

Saya mengalami masalah serupa ketika proyek baru saya bergantung pada oracle jdbc jar (yang telah saya instal di repositori lokal saya dan berfungsi dengan baik untuk proyek lain). Saya mencoba opsi -U, menghapus file .lastupdate atau seluruh direktori dan downlaod lagi, tetapi tidak berhasil. akhirnya, saya menghapus direktori dan menginstalnya secara lokal lagi, berhasil.


0

Salah satu kesalahan yang saya temukan di sekitar Maven adalah ketika saya meletakkan file settings.xml saya di direktori yang salah. Itu harus dalam folder .m2 di bawah direktori home user Anda. Periksa untuk memastikan itu ada di tempat yang benar (bersama dengan settings-security.xml jika Anda menggunakannya).


0

Saya pernah DependencyResolutionExceptionmenggunakan Ubuntu Linux ketika saya menginstal artefak lokal melalui skrip shell. Solusinya adalah menghapus artefak lokal dan menginstalnya lagi "secara manual" - menelepon mvn install:install-filemelalui terminal.


0

Ini terjadi karena saya httpbukannya httpsdalam ini:

<repository>
    <id>jcenter</id>
    <name>jcenter-bintray</name>
    <url>https://jcenter.bintray.com</url>
</repository>

0

periksa apakah artefak Y Anda memiliki kemasan yang disetel ke "jar". Jika Anda telah mendefinisikannya sebagai "perang" dengan kesalahan atau salin tempel, itu akan menunjukkan ini aneh "telah di-cache di repositori lokal, resolusi tidak akan diusahakan sampai interval pembaruan internal telah berlalu atau pembaruan dipaksa". Saya mengharapkan sesuatu seperti "artefak Y adalah perang, jenis jar diharapkan".


-1

Saya mengalami kesalahan yang sama dari penyebab yang berbeda: Saya telah membuat POM pemula yang berisi dependensi "praktik baik" kami, dan membangun & menginstalnya secara lokal untuk mengujinya. Saya bisa "melihatnya" di repo, tetapi proyek yang menggunakannya mendapat kesalahan di atas. Yang saya lakukan adalah mengatur starter POM ke pom, jadi tidak ada JAR. Maven benar sekali bahwa itu tidak ada di Nexus - tapi saya tidak mengharapkannya, jadi kesalahan itu, ummm, tidak membantu. Mengubah POM starter ke kemasan normal & menginstal ulang memperbaiki masalah.


Jawaban ini mungkin lebih baik sebagai komentar, karena ini bukan jawaban langsung atas pertanyaan.
00prometheus
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.