Akui, kami semua bekerja membangun gedung di Maven untuk malam dan malam yang panjang, dan pada saat itu saya benar-benar ingin memberi tahu beberapa pencipta teknologi yang luar biasa ini. Terkadang mimpi menjadi kenyataan! Zhenya dan saya (
phillenium )
menemukan pengembang Maven yang paling utama - Robert Scholte. Dan apa yang kami tanyakan kepadanya tentang ...
Baca lebih lanjut →
Dengan siklus rilis baru, versi Java keluar satu demi satu, yang kesebelas telah muncul, sementara banyak yang duduk di urutan ke delapan. Anda akan segera memberikan presentasi tentang bagaimana Maven mendukung semua ini, dan Anda tidak ingin merusak laporan, tetapi ajukan pertanyaan ke arah ini. Apa yang Anda pikirkan secara pribadi tentang siklus rilis baru ini yang menambahkan pekerjaan bagi Anda? Apakah ini perubahan untuk menjadi lebih baik atau lebih buruk?
Jika Anda berbicara tentang siklus rilis 6 bulan, maka untuk Maven itu agak cepat. Tim kami cukup kecil, kami memiliki sekitar 5-10 peserta aktif, dan mereka semua adalah sukarelawan, tidak ada perusahaan yang mengembangkan Maven. Jadi, setiap orang harus mengerjakan proyek di waktu luang mereka. Perubahan di Jawa membuat banyak pekerjaan. Setiap kali versi baru dirilis, kami perlu memberikan dukungannya, yang berarti bahwa kami tidak punya waktu untuk Maven, plugin untuk itu, atau apa pun. Akan lebih baik bagi saya jika siklus itu satu atau setengah tahun.
Apakah orang lain yang mengembangkan proyek untuk ekosistem Jawa memiliki perasaan yang sama, yang juga perlu memberikan dukungan untuk versi terbaru?
Dilihat oleh twitter, maka ya, sebagian besar setuju bahwa 6 bulan terlalu cepat.
Bisakah Anda menceritakan kisah Maven? Jika saya ingat dengan benar, itu dibuat sejak lama untuk membuat Turbin Apache tidak terlalu menakutkan dan menyakitkan. Kebetulan, saya menggunakan Apache Turbine. Apakah Anda ingat saat ini?
Kisah Maven dimulai sejak lama. Saya bergabung dengan proyek ini sekitar 8 tahun yang lalu, yaitu selama versi 3.0.3 atau 3.0.4. Dan pada titik ini, Maven telah ada selama beberapa waktu. Sejauh yang saya tahu, dia adalah bagian dari proyek Turbin. Alat terpisah dibuat dari bagian proyek ini, yang menjadi Maven. Saya, seperti mungkin semuanya, menggunakan Semut kemudian. Saya tidak suka itu setiap kali saya mulai mengerjakan proyek baru, saya perlu menyalin semua file Ant ini. Saya tahu bahwa harus ada solusi yang lebih baik, saya mulai mencarinya di Internet dan menemukan Maven. Namun, sebelum saya memahami ide utama Maven, banyak waktu berlalu. Namun, ketika Anda memahaminya, itu menjadi nyaman. Semua masalah yang saya miliki dengan Ant menghilang. Semut masih merupakan alat yang hebat, tetapi jika Anda mengerjakan proyek yang menggabungkan banyak sumber, saya sangat merekomendasikan Maven atau alat serupa.
Maven hanya tentang Jawa. Saya mencoba menggunakannya untuk C ++, tapi itu tidak terlalu bagus. Apakah ada saat ketika Java tidak lagi ada, dan apa yang akan kita lakukan?
Dari bahasa berorientasi objek populer yang ada, Jawa tampaknya menjadi salah satu yang tertua, sudah lebih dari 20 tahun. Saya tidak melihat statistik terbaru, tetapi saya yakin bahwa Jawa masih sangat luas. Saya pikir itu akan ada selama beberapa waktu. Setidaknya saya harap begitu - itu artinya saya tidak akan dibiarkan tanpa pekerjaan.
Akankah Maven hidup terlalu lama?
Tapi ini pertanyaan yang sulit. Hingga saat ini, 65-80% proyek Jawa menggunakan Maven. Bahkan untuk produk yang sudah lebih dari 15 tahun, ini banyak sekali. Mungkin, lebih banyak lagi yang bisa ditingkatkan di Maven. Kami punya ide untuk Maven 4 dan bahkan Maven 5. Tetapi akan membutuhkan waktu lama untuk mengimplementasikannya. Saya pikir ide umum Maven tidak akan menjadi usang, tetapi sistem perakitan lainnya mungkin mengambil alih itu. Karena mereka mengekstrak pengalaman baik dari kesalahan yang kami buat di Maven dan dari keputusan yang kami buat dengan benar, dan berdasarkan pengalaman ini, mereka bisa mulai dari awal. Salah satu keunggulan Maven adalah kompatibilitas ke belakang. Bahkan proyek yang ditulis 10 atau 15 tahun yang lalu dapat dirakit menggunakan versi terbaru Maven. Tetapi karena ini, kami memiliki banyak kode lama di Maven Core. Ini harus diganti, tetapi ini tidak mudah.
Sejauh yang saya ingat, sekarang Anda masih bisa membangun moji tanpa penjelasan.
Ya itu mungkin.
Sebelum wawancara, saya mencoba mencari tutorial tentang ini, dan tidak menemukan apa pun. Seolah-olah para penyendiri mengejar kita dan menggerogoti semua dokumen lama di Internet. Tetapi saya ingat bahwa pada suatu waktu tidak ada penjelasan dan konvensi khusus digunakan. Yah dia, mari kita beralih ke pertanyaan lain. Apakah Anda pikir Maven memiliki persaingan nyata? Katakan Gradle?
Gradle adalah pesaing yang sangat kuat, dan telah ada selama beberapa waktu. Saya percaya bahwa memiliki persaingan itu baik, karena itu membuat kami tetap bugar dan memungkinkan kami melihat beberapa solusi alternatif. Mereka hanya memiliki pendekatan berbeda tentang cara mengumpulkan proyek, tidak ada yang salah dengan itu. Setiap orang harus memilih yang paling cocok dengan proyek mereka. Mungkin saya juga harus menyebutkan pro di sini . Ini adalah alat yang ditulis oleh Remi Forax dari tim ASM (bytecode parser). Dia, seperti saya, adalah anggota kelompok ahli proyek Jigsaw. Dia ingin menulis alat membangun yang paling mencerminkan ide-ide Jawa. Saat membuat pro, ia meminjam aspek terbaik dari Maven. Menonton ini menarik. Itu adalah demo yang dirancang untuk menunjukkan bahwa Anda dapat menggunakan modul Java 9 dan manfaat terkait di pembangun.
Anda mengatakan Anda berpartisipasi dalam proyek Jigsaw - dan Anda mengatakan itu dalam bentuk lampau. Dia tidak ada lagi? Apakah dia masih memiliki kesempatan untuk berkembang?
JSR ini ditutup. Benar, beberapa masalah yang belum terselesaikan masih ada, tetapi mereka sekarang ditangani oleh tim pendukung.
Apa yang menyebabkan paling sulit dalam mengembangkan Maven? Apa masalah yang paling serius? Tidak dalam hal Java 9, tetapi secara umum, berdasarkan semua pengalaman pengembangan. Bisakah Anda memilih, katakanlah, dua masalah yang paling penting?
Pertanyaannya tidak mudah, tapi mari kita coba. Bagian di mana resolusi ketergantungan terjadi sangat kompleks. Kami masih berusaha memperbaikinya. Anda mungkin telah memperhatikan bahwa tidak ada versi Maven 3.4, setelah versi 3.3.9 segera ada 3.5.0. Alasan utama untuk ini adalah bahwa ada perubahan signifikan dalam menyelesaikan dependensi. Mereka ditandai sebagai perbaikan bug, tetapi kami perhatikan bahwa sejumlah besar proyek tiba-tiba rusak - mereka bergantung pada perubahan aneh ini. Ini tidak bisa diterima. Oleh karena itu, kami melakukan apa yang tidak akan kami ambil dalam keadaan lain - repositori git hard-reset, dan di Maven 3.5.0 kami mulai memilih hanya perbaikan eksternal. Yah, dan, tentu saja, kami membuat konsol ini berwarna-warni - semua orang menyukainya.
Ok, sekarang ini kesulitan kedua!
Tidak mudah bagi kami untuk menemukan koneksi dengan komunitas Maven dan mengajari mereka cara menggunakan alat dengan benar.
Jadi semua orang tahu cara menggunakan Maven: salin beberapa footstraps XML dari komentar di Stack Overflow, dan itu berfungsi. Bukan begitu?
Baik, baik. Tidak. Saya yakin bahwa paling sering Anda akan disarankan untuk melakukan instalasi bersih, dan ini tidak benar. Jadi, mungkin, itu harus dilakukan di Maven 2. Sekarang Anda perlu menjalankan mvn memverifikasi. Karena ketika Anda membersihkan, semuanya dihapus, seluruh hasil pekerjaan. Dan jika file disalin dari Anda - ini adalah operasi I / O, mereka lambat. Secara umum, banyak hal akan dilakukan berulang kali. Sebagian besar plugin tahu kapan mereka perlu melakukan pekerjaan mereka. Sebagai aturan, tidak perlu bersih. Sedangkan untuk menginstal, perintah ini hanya menyalin file JAR Anda ke repositori lokal. Sekali lagi, ini adalah operasi I / O yang tidak perlu. Selain itu, repositori lokal Anda mungkin menjadi kotor - yaitu, mungkin terlihat berbeda dari repositori lokal rekan Anda. Terkadang ini dapat membawa hasil yang menarik. Jadi Anda harus menjalankan mvn memverifikasi, itu sudah cukup.
Omong-omong, saya baru saja membuka maven.apache.org , dan dikatakan: "Apache Maven adalah perangkat manajemen proyek dan alat pemahaman". Tetapi banyak orang berpikir Maven hanyalah alat pembangun lainnya. Apa perbedaan antara alat rakitan dan alat manajemen proyek?
Mungkin lebih baik tidak menjawab pertanyaan ini - bukan saya yang menulisnya di situs. Saya pikir penulis ingin mengatakan bahwa Maven lebih dari sekedar membangun sebuah proyek. Ia juga terlibat dalam menyelesaikan dependensi, ia menyediakan format konfigurasi, ia mengizinkan untuk tidak menginstal terlalu banyak hal. Secara umum, ini adalah koleksi besar segala sesuatu di dunia.
Apa prinsip dan kepercayaan utama tim Maven? Sebagai contoh, apakah mereka berpikir bahwa pendekatan deklaratif lebih baik daripada keharusan? Sesuatu seperti Zen dengan Python. Apakah Anda memiliki seperangkat aturan yang sama?
Saya kira tidak. Menurut pendapat kami, konfigurasi plugin harus dibuat sesederhana mungkin. Jika ada default yang masuk akal, mereka harus ditunjukkan. Ini akan membuat hidup lebih mudah bagi pengguna akhir. Untuk pertama kalinya dalam beberapa tahun, kami baru-baru ini mengubah opsi default untuk versi sumber dan target - sebelum 1,5, sekarang 1,6. Kami ingin opsi default untuk hadir, karena tanpa itu versi yang digunakan dalam JDK digunakan. Dalam hal ini, jika saya menggunakan Java 10, dan orang lain menggunakan Java 12, kami akan mendapatkan hasil yang berbeda. Anda harus selalu menentukan sumber dan target. Tetapi jika Anda mulai menggunakan Java 9, Anda tidak lagi dapat membuat Hello World dengan file pom sederhana dan satu kelas, karena Java 9 membutuhkan setidaknya Java 6 untuk nilai sumber dan target. Oleh karena itu, kami memutuskan untuk membuat versi standar 1.6 dan menambahkan peringatan bahwa jika Anda belum menentukan versi, ini harus dilakukan - orang-orang harus tahu bahwa Anda perlu mengatur versi sumber dan target atau nilai rilis jika Anda bekerja dengan Java 9. Atau keduanya.
Kesulitan apa yang Anda lihat untuk Maven di masa depan? Kamu bilang kamu mencoba untuk tidak mengubah Maven terlalu sering. Namun, apa yang menanti kita di masa depan?
Salah satu perubahan paling signifikan yang ingin kami lakukan terkait dengan file pom. Kami menemukan bahwa di beberapa bagian - terutama di build - alangkah baiknya menambahkan beberapa elemen tambahan. Tetapi untuk sekarang, kita tidak bisa melakukan ini. File pom yang sama yang Anda gunakan pada sistem Anda diunggah. Jika Anda menambahkan elemen lain ke dalamnya, mereka akan melanggar XSD, dan alat lain tidak akan dapat menggunakannya.
Tapi bisakah Anda mengubah XSD di header?
Ya Tapi saya tidak berpikir setiap alat memeriksa XSD. Mereka hanya berpikir bahwa mereka sedang berhadapan dengan versi 4.0.0. Jadi membuat perubahan akan sangat sulit. Kami memutuskan bahwa kami akan membagi file pom menjadi beberapa bagian dan mulai dengan Build POM. Dan yang akan diturunkan akan disebut Consumer POM. Ini akan dihasilkan berdasarkan Build POM dan tidak ada tindakan lebih lanjut yang diperlukan. Dan itu akan sepenuhnya kompatibel dengan Maven POM 4.0.0. Dengan membagi POM menjadi dua bagian, kita akhirnya dapat meningkatkannya secara signifikan dan membuat Maven lebih mudah digunakan. Ini adalah perubahan pada inti Maven, dan kami telah mengusahakannya lebih dari setahun, termasuk implementasi dalam IDE. Ini tidak mudah.
Beberapa IDE mencoba memasukkan bagian Maven dalam IDE untuk alasan integrasi, penyelesaian otomatis, kompilasi tambahan, dan sebagainya. Bagaimana cara melakukannya dengan benar? Sejauh yang saya ingat, beberapa bagian Maven pernah dibangun di Eclipse dulu.
Saya pikir upaya seperti itu dapat dibenarkan - sistem ini sangat nyaman bagi pengguna karena integrasi. Ini dimungkinkan berkat salah satu perubahan signifikan yang diterapkan di Maven 3. Di dalamnya, arsitektur dibangun kembali untuk memberikan dukungan yang lebih baik dalam IDE. Penulis perubahan ini bekerja erat dengan Eclipse, dan solusi ini datang dari sini. Saya pikir ini dibolehkan. Saya tahu bahwa NetBeans dan InelliJ memiliki pendekatan yang sama sekali berbeda, mereka hanya memanggil Maven dari baris perintah tanpa integrasi apa pun.
Topik penting lainnya adalah kecepatan Maven. Bisakah kita meningkatkannya? Resolusi ketergantungan dan operasi I / O sangat lambat. Bahkan hari ini di SSD.
Ya, sesuatu bisa dilakukan. Pertama, Anda perlu melihat berapa banyak kernel di sistem Anda dan mulai Maven dengan beberapa utas. Ini adalah salah satu solusinya. Juga, lihat Takari. Ini adalah perusahaan yang dibuat oleh Jason van Zayl, salah satu pendiri Maven. Dia menulis beberapa ekstensi menarik dan secara signifikan meningkatkan dukungan untuk majelis paralel, yaitu ketika Anda membangun beberapa proyek. Saya berharap bahwa suatu hari nanti dia akan memberikan perkembangan ini kepada Maven, tetapi untuk sekarang Anda harus melihat halamannya.
Anda bilang Anda mengerjakan Maven di waktu senggang Anda, bukan? Apakah fakta bahwa Anda adalah salah satu pencipta Maven membantu dalam pekerjaan Anda saat ini? Atau hanya hobi?
Saya bekerja sebagai arsitek perangkat lunak di sebuah organisasi pemerintah di Belanda. Inilah cara saya mencari nafkah. Tentu saja, mereka tahu bahwa saya juga bekerja pada Maven, jadi mereka secara berkala bertanya kepada saya tentang Maven. Tapi secara keseluruhan, saya hanya arsitek mereka. Dan di malam hari, saya mengerjakan Maven, mencoba memperbaikinya, membantu orang.
Apakah Anda bekerja pada proyek sumber terbuka lainnya selain Maven?
Saya berpartisipasi dalam dua proyek lainnya. Salah satunya disebut MojoHaus, itu mengembangkan sebagian besar plugin untuk Maven. Benar, sekarang saya melakukan sedikit dalam proyek ini, tetapi masih kadang-kadang saya mencari di sana dan mengatur berbagai hal kecil. Proyek lain disebut QDox. Ini mem-parsing kode sumber. Ini juga terkait dengan Maven, karena digunakan dalam beberapa plugin untuk itu. Pengalaman ini membantu saya, karena, misalnya, dalam kasus deskriptor modul, diperkenalkan di Java 9, pengalaman memungkinkan saya untuk menggunakan deskriptor dalam plugin untuk Maven.
Omong-omong, apa pendapat Anda tentang Java 9, 10, 11? Haruskah saya menggunakannya, atau lebih baik tetap menggunakan Java 8?
Bermigrasi ke versi yang lebih baru. Bahkan jika Anda tidak menggunakan semua fitur, Anda harus meningkatkan ke Java 10, atau menunggu beberapa minggu dan meng-upgrade ke Java 11. Cukup gunakan classpath. Java secara signifikan lebih cepat berkat modularitasnya, tetapi classpath hanya berfungsi. Saya tahu bahwa masih banyak yang berpikir bahwa Anda perlu menambahkan deskriptor modul atau menggunakan sistem modul, tetapi ini tidak perlu. Cukup gunakan classpath.
Omong-omong, apakah Anda terbiasa dengan proyek GraalVM? Bagaimana kalau menggunakannya untuk membangun Maven?
Minggu lalu saya mengunjungi JavaZone dan mendiskusikan hal ini dengan Chris dan Oleg. Saya pikir kita perlu meluangkan waktu dengan ini, melihat apakah mungkin untuk benar-benar meningkatkan kinerja Maven dengan GraalVM. Mungkin menarik.
Anda adalah pencipta Maven, sebuah proyek yang sangat penting bagi pengembang Java. Apa perasaan Anda tentang ini?
Saya bukan pendiri proyek, saya terlibat dalam dukungannya. Saya mulai berurusan dengannya ketika dia sudah datang jauh, dan sepertinya saya bisa menerimanya. Sepuluh tahun yang lalu, saya tidak akan berpikir bahwa saya akan berakhir di puncak hierarki, tetapi itu terjadi, dan itu sangat keren. Setiap orang memiliki pendapat tentang Maven, dan saya sangat suka ketika Anda datang ke konferensi, orang-orang datang dan mengatakan bahwa mereka senang dengan Maven. Ini sangat memotivasi saya, dan memberi saya kekuatan untuk terus mengerjakan proyek ketika saya pulang.
Banyak pengembang sangat membenci XML. Saya bukan salah satu dari mereka, tetapi ketika datang untuk membangun sistem, topik ini selalu muncul karena pom.xml di Maven. Karena itu, saya ingin tahu: apa pendapat Anda tentang XML?
Hal yang baik tentang XML adalah semua orang memahaminya, mudah untuk menguraikannya, dan dapat memberikan dukungan yang sangat baik dalam IDE. Saya cukup normal dengan XML, dan sejauh yang saya tahu, di antara pengguna Maven tidak lebih dari 5% membenci XML - tetapi mereka meneriakkannya dengan keras! Dan Anda tidak pernah mendengar 95% sisanya. Namun demikian, ada solusi untuk 5% ini - di sini sekali lagi saya ingin menyebutkan Takari. Ada proyek polyglot yang memungkinkan Anda memilih sintaks yang berbeda. Jadi jika Anda ingin menggunakan Yaml dan pom.yml - ini sepenuhnya mungkin. Anda hanya perlu menambahkan ekstensi ke proyek, dan Anda dapat beralih ke bahasa lain.
Dan juga tentang suasana hati para pengembang: Saya ingat utas di milis Maven, di mana penulis alat SDKMAN! komunitas menanggapi proposal untuk mendistribusikannya Maven dengan frasa seperti "yang saya lihat adalah proyek dengan nama bodoh" dan "Anda bisa menjual ide Anda dengan lebih baik". Diskusi kemudian muncul: beberapa percaya bahwa komunitas bereaksi terlalu agresif, sementara yang lain - bahwa kalimat awal "melakukan tindakan tambahan sehubungan dengan alat saya" tidak berdasar. Dengan satu atau lain cara, banyak yang tidak senang dengan situasi itu, dan dalam hal ini pertanyaannya: apakah Anda berpikir bahwa secara khusus Maven atau komunitas open-source pada umumnya memiliki masalah komunikasi?
Komunikasi bisa sangat, sangat sulit, itu sudah pasti. Terutama ketika itu terjadi hanya melalui teks dan Anda tidak melihat lawan bicara di depan Anda - dalam situasi ini menjadi sulit untuk menjelaskan apa yang ingin Anda katakan. Saya pikir setiap proyek open source menghadapi masalah komunikasi yang benar dengan orang-orang. Saya sepenuhnya mengerti mengapa peserta proyek terkadang kesal - mereka mendengar pertanyaan yang sama berulang kali. Contoh dari pertanyaan seperti itu, yang telah saya sebutkan - "mengapa Anda tidak dapat menggunakan mvn clean install"? Saya berhenti menjelaskan ini, karena kalau tidak saya akan berubah menjadi orang yang kasar, tetapi saya tidak menginginkan ini. Jadi saya menjelaskan hal-hal seperti itu dengan cara lain. Jadi, di satu sisi, komunikasi bisa sangat sulit. Di sisi lain, meskipun Maven tidak fleksibel, itu adalah bagian dari kesuksesannya. Ketika orang-orang datang dengan penawaran yang tidak sesuai dengan konsep Maven kami, kami hanya mengatakan: maaf, tapi ini tidak sesuai dengan kami untuk beberapa alasan. Saya sepenuhnya mengerti bahwa ini bisa membuat frustrasi. Namun secara umum, pendekatan ini hanya untuk yang terbaik.
Bisakah Anda, pada akhirnya, mengatakan beberapa patah kata kepada pembaca kami, menyarankan bagaimana mereka bisa sampai ke masa depan yang cerah?
Seperti yang saya katakan, sebuah tim kecil sedang mengerjakan Maven, ini adalah proyek sumber terbuka di mana setiap orang dapat berpartisipasi. Tidak begitu sulit. Kami membuat label baru yang dipanggil untuk diperebutkan. Ini adalah masalah yang seharusnya tidak terlalu sulit untuk diperbaiki. Dengan cara ini, Anda bisa mengetahui cara kerja Maven. Jika Anda ingin bergabung dengan tim kami, maka dengan contoh perbaikan Anda, kami akan melihat kualitas kode Anda - jika Anda ingin diperhatikan oleh kami, maka saya sarankan untuk mencobanya. Saya ingin tim kami berkembang di masa depan.
Terima kasih atas jawabannya. Temui aku di Joker 2018!
Menit periklanan. Konferensi Joker 2018 akan diadakan pada 19-20 Oktober, di mana Robert akan memberikan presentasi tentang "Apache Maven mendukung ALL Java . " Secara umum, akan ada banyak laporan yang lebih menarik dan patut diperhatikan di Joker. Tiket dapat dibeli di situs resmi konferensi.