tentang kami
Di 1C kami membangunkan bukan sahaja platform pada ΠΈ , tetapi juga aplikasi Java - khususnya persekitaran pembangunan baharu berdasarkan Eclipse dan pelayan utusan yang terintegrasi secara mendalam dengan platform - .
Entry
Kami paling kerap menggunakan maven sebagai sistem binaan untuk aplikasi Java, dan dalam artikel pendek ini kami ingin bercakap tentang salah satu masalah yang perlu kami hadapi dalam proses mengatur pembangunan, dan mengenai pendekatan yang membolehkan kami mengatasi ini. masalah.
Prasyarat dan aliran kerja
Disebabkan kekhususan pembangunan dalam projek maven kami, kami menggunakan cukup banyak modul, kebergantungan dan projek kanak-kanak. Bilangan fail pom dalam satu pokok boleh dalam puluhan atau bahkan ratusan.
Nampaknya: bukan masalah besar, mereka menciptanya sekali dan melupakannya. Jika anda perlu menukar atau menambah sesuatu dalam semua fail sekali gus, terdapat banyak alat mudah dalam editor dan IDE. Apakah perubahan biasa yang paling biasa kepada pom.xml? Kami percaya bahawa perubahan dalam versi projek dan kebergantungan. Mungkin seseorang akan mahu berhujah dengan ini, tetapi ini adalah situasi yang berlaku dengan kita. Sebabnya terletak pada fakta bahawa, bersama-sama dengan kernel, kami membangunkan banyak perpustakaan kami sendiri secara serentak, dan untuk kebolehulangan berterusan hasil binaan dan ujian, menggunakan syot kilat nampaknya bukan pendekatan yang mudah bagi kami. Atas sebab ini, adalah perlu untuk menaikkan nombor versi dalam projek dengan setiap binaan.
Selain itu, dari semasa ke semasa, pembangun perlu membina cawangan perpustakaannya sendiri dan menyemak kefungsiannya terhadap semua kebergantungan, yang mana dia perlu menukar versi kesemuanya secara manual.
Penyelesaian awal
Dengan perubahan versi yang kerap dan berbilang, saya ingin memudahkan dan mengautomasikan proses dalam CI. Di sinilah pemalam yang mudah dan terkenal datang untuk menyelamatkan. versi-maven-plugin - sambungkannya dan lancarkannya
mvn -N versions:set -DnewVersion=2.0.1
dan Maven akan melakukan segala-galanya seperti yang sepatutnya: ia akan berjalan melalui hierarki dari atas ke bawah, menggantikan semua versi - kecantikan! Kini yang tinggal hanyalah untuk membangkitkan permintaan tarik, rakan sekerja akan menyemak perubahan dan anda boleh segera menyertai trunk. cepat? Tidak kira bagaimana keadaannya. Beberapa ratus pom.xml untuk semakan, dan ini tidak mengira kod. Di samping itu, tiada siapa yang selamat daripada konflik gabungan dengan sejumlah besar fail yang diubah. Perlu diingatkan di sini bahawa dalam proses CI, perubahan versi berlaku secara automatik bersama-sama dengan perubahan dalam fungsi, dan bukan secara berasingan.
Ciri-ciri baru
Untuk seketika kami bertenang dan, setelah meletak jawatan, kami hidup seperti itu sehingga orang-orang dari Bermula dari versi 3.5.0-beta-1, Maven tidak menyertakan sokongan untuk apa yang dipanggil "pemegang tempat". Intipati pengganti ini ialah pom.xml bukannya petunjuk khusus versi projek, pembolehubah digunakan ${revision}, ${sha1} ΠΈ ${changelist}. Nilai sifat ini sendiri ditetapkan sama ada dalam elemenhartanah>, atau ia boleh ditakrifkan melalui sifat sistem
mvn -Drevision=2.0.0 pakej bersih
Nilai harta sistem diutamakan daripada nilai yang ditakrifkan dalamhartanah>.
Ibu bapa
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-ibu bapa
First CI Friendly
${revision}${sha1}${changelist}
...
1.3.1
-GAMBAR GAMBAR
Keturunan
4.0.0
org.apache.maven.ci
ci-ibu bapa
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-anak
...
Jika anda ingin membina versi 2.0.0-SNAPSHOT, maka gunakan sahaja
mvn -Drevision=2.0.0 pakej bersih
Jika anda ingin membuat keluaran, maka tetapkan semula SNAPSHOT
mvn -Dchangelist= pakej bersih
*Contoh di atas diambil dari di tapak web Projek Apache Maven
Realiti yang keras
Semuanya baik dan sihat, sudah tiba masanya untuk merasai rasa kepuasan, tetapi tidak. Ternyata kaedah ini tidak akan berfungsi untuk memasang dan menggunakan, kerana ia tidak akan digantikan dalam perihalan artifak yang diterbitkan dalam repositori ${revision} pada maknanya dan maven tidak akan lagi memahami apa itu semua.
org.apache
apache
${revision}
Cahaya di hujung terowong
Kita perlu mencari penyelesaian kepada masalah tersebut. Boleh menyelamatkan keadaan . Pemalam ini menyelesaikan semua pembolehubah dalam pom, tetapi pada masa yang sama memotong banyak maklumat lain yang hanya diperlukan semasa pemasangan dan tidak diperlukan apabila mengimport artifak yang diterbitkan ke dalam projek lain. Pemalam itu juga "meluruskan" semua kebergantungan ibu bapa-anak, dan sebagai hasilnya, anda mendapat pom rata yang merangkumi semua yang anda perlukan. Kesulitan itu ialah ia memotong terlalu banyak "tambahan", yang tidak sesuai dengan kami sama sekali. Selepas mengkaji maklumat mengenai pembangunan pemalam ini, ternyata kita bukan satu-satunya di alam semesta, dan pada Ogos 2018, permintaan tarik dibuat di Github dalam repositori pemalam dengan keinginan untuk menjadikannya mungkin. untuk menentukan sendiri cara "merosakkan" pom.xml. Pembangun mendengar suara mereka yang menderita, dan sudah pada bulan Disember, dengan keluaran versi baharu 1.1.0, mod baharu, resolveCiFriendliesOnly, muncul dalam flatten-maven-plugin, yang lebih sesuai berbanding sebelum ini - ia meninggalkan pom.xml sebagaimana adanya, kecuali untuk elemen dan membenarkan ${revision}, ${sha1} ΠΈ ${changelist}.
Menambah pemalam pada projek
org.codehaus.mojo
flatten-maven-plugin
1.1.0
benar
resolveCiFriendliesSahaja
ratakan
proses-sumber
ratakan
ratakan.bersih
bersih
bersih
Selesai!
pengakhiran yang bahagia
Mulai sekarang, untuk menukar versi keseluruhan projek dan membiarkan semua kebergantungan mengetahuinya, kita hanya perlu mengedit elemensemakan> hanya dalam akar pom.xml. Bukan seratus atau dua daripada fail ini dengan perubahan yang sama tiba di semakan, tetapi satu. Nah, tidak perlu digunakan versi-maven-plugin.
Sumber: www.habr.com