Tentang kami
Di 1C kami tidak hanya mengembangkan platform pada ΠΈ , tetapi juga aplikasi Java - khususnya lingkungan pengembangan baru berdasarkan Eclipse dan server messenger yang terintegrasi secara mendalam dengan platform - .
Masuk
Kami paling sering menggunakan maven sebagai sistem pembangunan untuk aplikasi Java, dan dalam artikel singkat ini kami ingin berbicara tentang salah satu masalah yang harus kami hadapi dalam proses pengorganisasian pengembangan, dan tentang pendekatan yang memungkinkan kami untuk mengatasinya. masalah.
Prasyarat dan alur kerja
Karena kekhususan pengembangan dalam proyek pakar kami, kami menggunakan cukup banyak modul, dependensi, dan proyek turunan. Jumlah file pom dalam satu pohon bisa mencapai puluhan bahkan ratusan.
Tampaknya: bukan masalah besar, mereka membuatnya sekali dan melupakannya. Jika Anda perlu mengubah atau menambahkan sesuatu di semua file sekaligus, ada banyak alat yang mudah digunakan di editor dan IDE. Apa perubahan reguler yang paling umum pada pom.xml? Kami percaya bahwa perubahan dalam versi dan ketergantungan proyek. Mungkin seseorang ingin berdebat dengan hal ini, tetapi inilah yang terjadi pada kita. Alasannya terletak pada kenyataan bahwa, bersama dengan kernel, kami secara bersamaan mengembangkan banyak perpustakaan kami sendiri, dan agar hasil build dan pengujian dapat direproduksi secara konstan, penggunaan snapshot tampaknya bukan pendekatan yang nyaman bagi kami. Untuk alasan ini, nomor versi dalam proyek perlu ditingkatkan pada setiap build.
Selain itu, dari waktu ke waktu, pengembang perlu membangun cabang perpustakaannya sendiri dan memeriksa fungsinya terhadap semua dependensi, sehingga ia harus mengubah versi semuanya secara manual.
Solusi awal
Dengan perubahan versi yang sering dan berulang, saya ingin menyederhanakan dan mengotomatiskan proses dalam CI. Di sinilah plugin yang nyaman dan terkenal bisa membantu. versi-maven-plugin - sambungkan dan luncurkan
mvn -N versi:set -DnewVersion=2.0.1
dan Maven akan melakukan segalanya sebagaimana mestinya: ia akan berjalan melalui hierarki dari atas ke bawah, menggantikan semua versi - cantik! Sekarang yang tersisa hanyalah mengajukan permintaan tarik, kolega akan meninjau perubahannya, dan Anda dapat dengan cepat bergabung dengan trunk. Dengan cepat? Tidak peduli bagaimana keadaannya. Beberapa ratus pom.xml untuk ditinjau, dan ini belum termasuk kodenya. Selain itu, tidak ada yang kebal dari konflik penggabungan dengan begitu banyak file yang diubah. Perlu dicatat di sini bahwa dalam proses CI, perubahan versi terjadi secara otomatis seiring dengan perubahan fungsionalitas, dan tidak secara terpisah.
Fitur baru
Untuk sementara kami menenangkan diri dan, setelah berdamai, kami hidup seperti itu sampai orang-orang keluar Mulai dari versi 3.5.0-beta-1, Maven tidak menyertakan dukungan untuk apa yang disebut βplaceholderβ. Inti dari pengganti ini adalah itu pom.xml alih-alih indikasi spesifik versi proyek, variabel digunakan ${revisi}, ${sha1} ΠΈ ${daftar perubahan}. Nilai dari properti ini sendiri diatur dalam elemenproperties>, atau dapat ditentukan melalui properti sistem
mvn -Drevision=2.0.0 paket bersih
Nilai properti sistem lebih diutamakan daripada nilai yang ditentukan dalamproperties>.
Orang tua
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-orang tua
Ramah CI Pertama
${revisi}${sha1}${daftar perubahan}
...
1.3.1
-FOTO
Keturunan
4.0.0
org.apache.maven.ci
ci-orang tua
${revisi}${sha1}${daftar perubahan}
org.apache.maven.ci
ci-anak
...
Jika ingin membangun versi 2.0.0-SNAPSHOT, gunakan saja
mvn -Drevision=2.0.0 paket bersih
Jika ingin membuat rilis, maka reset saja SNAPSHOT
mvn -Dchangelist= paket bersih
*Contoh di atas diambil dari di situs web Proyek Maven Apache
Kenyataan yang pahit
Semuanya baik-baik saja dan sehat, saatnya merasakan rasa puas, tapi tidak. Ternyata metode ini tidak akan berfungsi untuk instalasi dan penerapan, karena tidak akan diganti dalam deskripsi artefak yang dipublikasikan di repositori ${revisi} tentang maknanya dan pakar tidak akan lagi memahami maksudnya.
org.apache
apache
${revisi}
Cahaya di ujung terowongan
Kita perlu mencari solusi untuk masalah ini. Bisa menyelamatkan situasi . Plugin ini menyelesaikan semua variabel di pom, tetapi pada saat yang sama menghilangkan banyak informasi lain yang hanya diperlukan selama perakitan dan tidak diperlukan saat mengimpor artefak yang diterbitkan ke proyek lain. Plugin ini juga βmeluruskanβ semua ketergantungan orangtua-anak, dan sebagai hasilnya, Anda mendapatkan pom datar yang mencakup semua yang Anda butuhkan. Ketidaknyamanannya adalah terlalu banyak "ekstra" yang dipotong, yang tidak cocok untuk kami sama sekali. Setelah mempelajari informasi tentang pengembangan plugin ini, ternyata kita bukan satu-satunya di alam semesta, dan pada bulan Agustus 2018, sebuah pull-request dibuat di Github di repositori plugin dengan keinginan untuk mewujudkannya. untuk menentukan sendiri bagaimana cara βmerusakβ pom.xml. Para pengembang mendengarkan suara-suara mereka yang menderita, dan pada bulan Desember, dengan dirilisnya versi baru 1.1.0, mode baru, resolusiCiFriendliesOnly, muncul di plugin flatten-maven, yang lebih cocok dari sebelumnya - ia pergi pom.xml apa adanya, kecuali elemennya dan memungkinkan ${revisi}, ${sha1} ΠΈ ${daftar perubahan}.
Menambahkan plugin ke proyek
org.codehaus.mojo
plugin-maven-ratakan
1.1.0
BENAR
menyelesaikanCiFriendliesOnly
meratakan
sumber daya proses
meratakan
ratakan.bersihkan
membersihkan
membersihkan
Selesai!
Akhir yang bahagia
Mulai sekarang, untuk mengubah versi keseluruhan proyek dan memberi tahu semua dependensi, kita hanya perlu mengedit elemennyarevisi> hanya di root saja pom.xml. Bukan seratus atau dua file dengan perubahan yang sama yang sampai pada tinjauan, tetapi satu. Yah, tidak perlu digunakan versi-maven-plugin.
Sumber: www.habr.com