Xgboost: [jvm-packages] Menerbitkan xgboost4j dan lainnya ke Maven Central

untuk platform, karena XGBoost tidak berfungsi untuk sistem 32bit

kita hanya perlu merawat 64 linux/win/osx

cara yang saya sukai secara pribadi untuk menerbitkan ke maven adalah memuat semuanya dalam satu toples

http://central.maven.org/maven2/org/xerial/snappy/snappy-java/1.1.2.6/

Anda dapat mengunduh snappy-java-1.1.2.6.jar dan melihat struktur lib asli mereka

Saya akan lihat, terima kasih. Apa yang saya tidak mengerti adalah bagaimana proses pembangunan diatur dalam kasus ini: itu mungkin berarti bahwa mereka memiliki beberapa repositori internal dengan binari, kemudian mereka menariknya dari sana selama proses pembangunan, dan hanya setelah itu mempublikasikan toples.

Memiliki beberapa toples mungkin merupakan keuntungan karena tidak perlu untuk itu: kita dapat menggunakan pusat maven sebagai repositori tersebut.

Tapi aku harus melihat lebih dekat.

Saya mencoba pendekatan multi-modul - tampaknya lebih alami bagi saya dan, tidak seperti pendekatan satu-modul-memiliki-mereka-semua, saya punya ide bagaimana menerapkannya.

Cara saya pikir itu bisa berhasil adalah sebagai berikut. Misalkan ada 3 orang A, dengan mesin linux, B, dengan windows, dan C dengan mac.

Ketika versi berikutnya siap dirilis ke maven, A mengambil versi xgboost4j saat ini (misalnya 0.7-SNAPSHOT), dan menggunakan plugin maven-release melakukan ini:

• memperbarui versi ke 0.7
• merilis lib asli linux bersama dengan modul Java lainnya ke maven
• melakukan perubahan versi ke git
• memperbarui versi ke 0.8-SNAPSHOT, melakukan perubahan lagi

Setelah ini selesai, B dan C dapat checkout versi 0,7 dari git, dan kemudian membangun dan menerbitkan hanya modul asli.

Tentu saja, ada kemungkinan bahwa B atau C melakukan rilis utama dan yang lain hanya menerbitkan binari.

Saya bereksperimen di garpu saya di sini: https://github.com/alexeygrigorev/xgboost

Bagaimana menurutmu?

Saya akan lihat, terima kasih. Apa yang saya tidak mengerti adalah bagaimana proses pembangunan diatur dalam kasus ini: itu mungkin berarti bahwa mereka memiliki beberapa repositori internal dengan binari, kemudian mereka menariknya dari sana selama proses pembangunan, dan hanya setelah itu mempublikasikan toples.

Memiliki beberapa toples mungkin merupakan keuntungan karena tidak perlu untuk itu: kita dapat menggunakan pusat maven sebagai repositori tersebut.

Mereka memiliki perpustakaan asli yang dibuat sebelumnya https://github.com/xerial/snappy-Java/tree/7650aa29fb52c3ba467e9c906cf22a3dab536861/src/main/resources/org/xerial/snappy/native

dan

memuatnya dengan https://github.com/xerial/snappy-java/blob/7650aa29fb52c3ba467e9c906cf22a3dab536861/src/main/Java/org/xerial/snappy/SnappyLoader.java

hanya akan ada satu perpustakaan di pusat maven

OK jadi itu berarti mereka menyimpan binari di git? Saya tidak yakin itu ide yang bagus.

Bagaimanapun, eksperimen saya dengan build multi-modul tampaknya berhasil: Saya berhasil menyebarkan binari dan toples ke snapshot nexus sonatype. Ini dia: https://oss.sonatype.org/content/repositories/snapshots/ml/dmlc/xgboost/

Saya hanya memiliki mesin linux dan windows, jadi saya hanya mencoba keduanya.

Saat ini menggunakan versi snapshot harus dimungkinkan dengan cara ini:

<project>
...
  <repositories>
    <repository>
      <id>sonatype-shapshot</id>
      <name>Sonatype Snapshot Repository</name>
      <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
    </repository>
  </repositories>
  <dependencies>
    <dependency>
      <groupId>ml.dmlc.xgboost</groupId>
      <artifactId>xgboost4j</artifactId>
      <version>0.7-SNAPSHOT</version>
    </dependency>
    ...
  </dependencies>
</project>

Ini harus secara otomatis mengunduh versi asli yang sesuai tergantung pada platform.

Untuk linux tampaknya berfungsi dengan baik, tetapi untuk windows perlu perpustakaan tambahan - jadi saya mungkin perlu mencoba ini dengan mesin virtual bersih dengan hanya Java dan maven yang diinstal dan lihat apakah itu berfungsi.

Juga, saya perlu mematikan pembuatan jar-dengan-dependensi - nexus sonatype tidak mengizinkan pengunggahan file besar. Guci ini dapat dibuat dengan profil khusus.

Setelah kami menyetujui semuanya, maka saya dapat membuat permintaan tarik dan kami dapat memublikasikan XGBoost ke repositori Rilis Sonatype, yang disinkronkan dengan maven central.

Itu tidak mengatakan bahwa kita perlu menyimpan binari di git..Alasan mereka memiliki perpustakaan asli bawaan yang disimpan di sana adalah karena mereka berencana untuk mendukung banyak pkatform termasuk yang dengan rantai alat yang sulit digunakan....

Tujuan kami hanya untuk mendukung 64-bit linux/mac/win. Kami hanya perlu melakukan apa yang kami lakukan: kompilasi libs asli-> salin ke direktori sumber daya -> build jar

Saya masih tidak mengerti mengapa perlu mengunggah banyak toples ke pusat maven repo...

Mungkin tidak perlu tetapi saya tidak tahu bagaimana mengatur proses pembuatan tanpanya.

Seperti yang saya tulis sebelumnya, menurut pendapat saya batasan pendekatan satu-jar-aturan-mereka-semua adalah bahwa pertama-tama kita perlu membangun kode untuk setiap platform target, menyimpan binari di suatu tempat, dan kemudian selama publikasi untuk ahli menarik binari dari sana dan masukkan ke dalam toples terakhir. Saya tidak tahu bagaimana melakukannya.

Ketika datang ke beberapa modul, itu masih tidak ideal, tetapi memecahkan masalah ini, dan proses pembangunan diatur seperti yang saya tulis sebelumnya.

Jadi saya mungkin menyarankan untuk mengikuti pendekatan yang saya usulkan dan memiliki binari di pusat lebih cepat daripada nanti, dan kemudian mungkin seseorang dengan pengetahuan maven yang lebih baik dapat memodifikasinya dan melakukannya dengan lebih baik.

Seperti yang saya tulis sebelumnya, menurut pendapat saya batasan pendekatan satu-jar-aturan-mereka-semua adalah bahwa pertama-tama kita perlu membangun kode untuk setiap platform target, menyimpan binari di suatu tempat, dan kemudian selama publikasi untuk ahli menarik binari dari sana dan masukkan ke dalam toples terakhir. Saya tidak tahu bagaimana melakukannya.

Mengapa menyimpan binari di suatu tempat? bagaimana kalau meletakkan semua perpustakaan asli di disk lokal (direktori sumber daya), memasukkannya ke dalam toples saat membangun dan akhirnya menerbitkan toples ke maven?

Oke, jadi bagaimana Anda akan melakukan ini? Seseorang membangun binari untuk windows dan kemudian mengirimkannya melalui email ke orang yang menggunakan linux?

Itu pertanyaan lain yang saya tidak mengerti ...

Mengapa kita harus melibatkan lebih dari satu orang untuk cross building? Sulit membayangkan proses rilis program membutuhkan dua orang....

Di rockdb, mereka menggunakan gelandangan untuk membangun silang ubuntu dan mac...xgboost tidak memiliki panggilan sistem itu atau yang lainnya, kedua platform ini dapat berbagi file lib asli yang sama di sebagian besar kasus..

Untuk windows, saya bukan ahli dalam pemrograman win ... bahkan vargrant tidak berfungsi, manual dalam-VM akan mencapai tujuan yang sama

Pertanyaan selanjutnya untuk didiskusikan adalah... bisakah kita melewati windows saat merilis ke maven? Alasan utamanya adalah kami tidak memiliki cukup tes (nol?) pada xgboost4j di bawah windows ...

Yah kita mungkin tidak perlu melibatkan lebih dari satu pengguna, tapi saya juga bukan ahli dalam vargrant, maaf.

Tetapi apa yang saya sarankan memang membutuhkan tiga pengguna:

• pengguna dengan linux membangun xgb dan menjalankan mvn deploy . Ini hanya menerbitkan versi linux.
• pengguna dengan windows dan mac build xgb dan menjalankan mvn --projects xgboost4j-native-windows deploy dan mvn --projects xgboost4j-native-osx deploy masing-masing.

Ini untuk menerbitkan versi snapshot, build rilis akan sedikit lebih rumit, tetapi saya menguraikannya di atas. Karena saya tidak terbiasa dengan vargrant dan alat virtualisasi lainnya, saya tidak tahu bagaimana mengaturnya dengan lebih baik.

Beri tahu saya jika proposal saya menarik bagi Anda, jika tidak, saya akan menunda upaya saya saat ini.

Saya akan berbicara dengan orang-orang mxnet untuk memahami jika ada alasan lain bagi mereka untuk memiliki banyak toples di mvn central

Saya berhasil membuat toples dengan Windows dll, Mac OSX macports dylib dan Linux, dan menyimpannya di artifactory kami yang berfungsi cukup baik. Terlepas dari ketika seseorang yang menggunakan minuman mencoba menggunakan macports dylib dan itu memberikan perpustakaan aneh yang tidak ditemukan kesalahan.

@alexeygrigorev Saya menantikan untuk mendapatkan OS windows xgboost-spark JAR dari repositori pusat pakar atau lainnya, saya melanggar kode di alat IntelliJ IDEA windows OS, kemudian menjalankan proyek di sistem produksi Linux, karena itu adalah debugging yang nyaman. Dalam pengalaman saya, mudah untuk mengkompilasi xgboost di OS Linux, tetapi di OS windows, saya tidak pernah berhasil. Jadi jika Anda telah melakukannya, tolong beri tahu saya, terima kasih banyak.

Saya memiliki masalah yang sama dengan @Frank111 .

Harap publikasikan xgboost ke Maven dengan pustaka asli yang dibundel untuk semua arsitektur.

Bahkan untuk arsitektur non-x86?

@CodingCat Ya, untuk semua arsitektur yang didukung XGBoost4J.

Silakan bundel pustaka asli ke dalam paket Maven dan muat pada saat runtime tergantung pada aplikasi arsitektur apa yang sedang berjalan.

Atau setidaknya izinkan untuk memilih arsitektur asli melalui penautan dengan paket Maven yang berbeda pada waktu pembuatan aplikasi (bukan waktu pembuatan perpustakaan Anda!), seperti yang dilakukan DeepLearning4J.

Bagaimanapun, membangun dari sumber hanya untuk memilih backend multithreading tidak diperlukan. Dan paket Maven harus cukup untuk penggunaan perpustakaan.

Saya juga akan sangat menghargainya jika setidaknya rilis utama XGBoost4J akan tersedia melalui Maven.

Saya juga menggunakan DeepLearning4J, yang sangat nyaman digunakan dibandingkan dengan XGBoost4J. Sementara itu dl4j bahkan menawarkan build malam di maven.

Menurut pendapat saya, hilangnya build XGBoost4J yang andal adalah masalah besar untuk kasus penggunaan yang lebih serius untuk perpustakaan hebat ini. Terutama di Windows, membangun XGBoost4J adalah petualangan yang berat;)

@mjakobus Ya, saya memiliki perasaan yang sama: XGBoost4J kehilangan rilis utama reguler dan terutama paket yang dirilis Maven dengan backend asli yang dipilih saat runtime.

Bagaimana orang menggunakan ini dalam produksi jika tidak di pusat pakar? Buat file JAR secara manual?

Di Criteo kami membangun JAR XGBoost di Travis/Appveyor. Secara teori, skrip yang sama dapat digunakan kembali untuk menerbitkan JAR resmi untuk XGBoost, tetapi saya tidak punya waktu untuk melakukannya.

Kami hanya menempatkannya secara manual ke nexus kami
(Dengan "secara manual" maksud saya melalui pakar, tetapi tidak dengan cara yang dikonfigurasi CI)

jadi pom berfungsi untuk menghasilkan artefak melalui perintah pembuatan jar maven standar? Dan apakah ini sudah diuji di lingkungan linux?

Dalam kasus kami - ya, dan kami melakukannya hanya untuk mesin linux

Saya telah membangun multi-jar dengan perpustakaan Linux, Windows dan Mac, dan meletakkannya di sebuah artifactory. Bekerja dengan baik dari sana.

Di BlaBlaCar kami membangunnya lalu mempublikasikannya ke nexus internal. Kemudian aplikasi mengambil dari nexus. Ini bukan multi-jar, jadi kami memiliki perpustakaan Linux dan Mac secara terpisah. Aplikasi kemudian mendapatkan ketergantungan yang tepat, misalnya, menggunakan Os.isFamily(Os.FAMILY_MAC) . Akan sangat bagus untuk memiliki multi-guci out-of-the-box. @Craigacp apakah multi-jar Anda tersedia di suatu tempat?

Sayangnya versi saya tidak tersedia, tetapi logika di XGBoost4J menyebabkannya memuat biner yang benar berdasarkan platform, jadi yang perlu Anda lakukan hanyalah membuka zip setiap toples, menyalin dll, jadi dan dylib ke direktori sumber daya yang sama dan rejar dia. Jika Anda memerlukan beberapa versi linux, pendekatan ini tidak akan berfungsi, karena logika pemuatan tidak cukup rumit (sama halnya gagal jika Anda memiliki banyak file untuk platform yang berbeda misalnya Linux & Solaris).

@edumucelli Anda dapat merakit multi JAR dengan menjalankan download_latest_release.py dari sini .

Itu dibangun untuk CentOS6 yang diakui kuno, jadi harus bekerja pada CentOS7 serta distribusi Linux yang lebih baru.

@superbobry , itu bagus! Terima kasih telah membagikannya!

@alexeygrigorev @CodingCat @edumucelli apa hasil dari ini?
Apakah ada solusi untuk secara otomatis membangun JAR untuk xgboost dan mempublikasikannya di suatu tempat?

Ada, ya. Saat ini dimungkinkan untuk melakukan mvn publish dan itu akan menyebarkannya ke repositori nexus lokal Anda

@Obarros Saya menggunakan multi JAR @superbobry pada wadah berbasis Debian dalam produksi.

untuk siapa saja yang ingin menggunakan xgboost versi pra-bangun, silakan periksa file README di https://github.com/dmlc/xgboost/tree/master/jvm-packages , kami telah menerbitkan artefak ke maven central

@CodingCat , @edumucelli Terima kasih!

@CodingCat bisakah Anda juga mendorong artefak windows juga? Artefak yang diterbitkan hanya berisi versi linux. Terima kasih

@bluelu , ini berisi Linux dan MacOS.

@edumucelli ini telah dibahas di dmlc/xgboost#3276. tl;dr @CodingCat memutuskan untuk tidak mendukung Windows untuk JAR Pusat Maven.

Kami memiliki beberapa JAR prebuilt di criteo-forks/xgboost-jars yang datang dengan Windows DLL.

Hai, tidak apa-apa bagiku. Saya telah membangun versi saya sendiri, namun itu akan membantu orang lain tentu saja jika itu akan tersedia tanpa harus mengkompilasi sendiri.

@superbobry terima kasih atas tautan ke utas itu. Itu bukan masalah, saya hanya melengkapi komentar @bluelu tentang toples khusus linux, yang sebenarnya memiliki dlyb MacOS juga.