Xgboost: [jvm-packages] Публикация xgboost4j и других в Maven Central

для платформы, поскольку XGBoost не работает для 32-битных систем

нам нужно только заботиться 64 linux / win / osx

мой личный предпочтительный способ публикации в maven - содержать все в одной банке

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

вы можете скачать snappy-java-1.1.2.6.jar и посмотреть структуру их собственных библиотек

Я посмотрю, спасибо. Я не понимаю, как в этом случае организован процесс сборки: это может означать, что у них есть какой-то внутренний репозиторий с двоичными файлами, затем они извлекают их оттуда во время процесса сборки и только после этого публикуют jar.

Наличие нескольких jar-файлов может быть преимуществом, потому что в этом не будет необходимости: мы можем использовать maven central в качестве такого репозитория.

Но мне нужно присмотреться.

Я пробую подход с несколькими модулями - мне он кажется более естественным, и, в отличие от подхода с одним модулем, есть все, у меня есть идеи, как его реализовать.

Я думаю, что это могло бы сработать следующим образом. Предположим, есть 3 человека: A с Linux-машиной, B с окнами и C с Mac.

Когда следующая версия будет готова к выпуску для maven, A берет текущую версию xgboost4j (например, 0.7-SNAPSHOT) и с помощью плагина maven-release делает следующее:

• обновляет версию до 0.7
• выпускает встроенную библиотеку linux вместе с другими модулями Java для maven
• фиксирует изменение версии на git
• обновляет версию до 0.8-SNAPSHOT, снова фиксирует изменение

После этого B и C могут получить версию 0.7 из git, а затем собрать и опубликовать только собственные модули.

Конечно, возможно, что B или C сделают основной выпуск, а другие просто опубликуют двоичные файлы.

Я здесь экспериментирую со своей вилкой: https://github.com/alexeygrigorev/xgboost

Что вы думаете?

Я посмотрю, спасибо. Я не понимаю, как в этом случае организован процесс сборки: это может означать, что у них есть какой-то внутренний репозиторий с двоичными файлами, затем они извлекают их оттуда во время процесса сборки и только после этого публикуют jar.

Наличие нескольких jar-файлов может быть преимуществом, потому что в этом не будет необходимости: мы можем использовать maven central в качестве такого репозитория.

У них есть предварительно созданные собственные библиотеки https://github.com/xerial/snappy-java/tree/7650aa29fb52c3ba467e9c906cf22a3dab536861/src/main/resources/org/xerial/snappy/native

а также

загрузите их с помощью https://github.com/xerial/snappy-java/blob/7650aa29fb52c3ba467e9c906cf22a3dab536861/src/main/java/org/xerial/snappy/SnappyLoader.java

в центральном maven будет только одна библиотека

ОК, значит, они хранят двоичные файлы в git? Не уверен, что это хорошая идея.

В любом случае, мои эксперименты с многомодульной сборкой, похоже, сработали: мне удалось развернуть двоичные файлы и банки в связке моментальных снимков sonatype. Вот он: https://oss.sonatype.org/content/repositories/snapshots/ml/dmlc/xgboost/

У меня есть только машины с Linux и Windows, поэтому я пробовал только эти две.

Прямо сейчас использование версий моментальных снимков должно быть возможно следующим образом:

<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>

Это должно автоматически загрузить соответствующую собственную версию в зависимости от платформы.

Для linux это работает хорошо, но для Windows нужны дополнительные библиотеки, поэтому мне, возможно, придется попробовать это на чистой виртуальной машине с установленными только java и maven и посмотреть, работает ли это.

Кроме того, мне нужно было отключить сборку jar-with-dependencies - нексус sonatype не позволяет загружать большие файлы. Эти банки могут быть изготовлены из специального профиля.

Как только мы обо всем договоримся, я могу создать пул-реквест, и мы сможем опубликовать XGBoost в репозитории Sonatype Release, который синхронизируется с maven central.

Это не говорит о том, что нам нужно хранить двоичные файлы в git ... Причина, по которой они сохранили встроенные собственные библиотеки, заключается в том, что они планируют поддерживать многие платформы pkatform, в том числе с трудными в использовании инструментами ....

Наша цель - поддерживать только 64-битные linux / mac / win. Нам нужно только сделать то, что мы делаем: скомпилировать собственные библиотеки -> скопировать в каталог ресурсов -> создать jar

Я все еще не понимал, зачем загружать много банок в центральное репозиторий maven ...

Возможно, в этом нет необходимости, но я не знаю, как организовать процесс сборки без этого.

Как я писал ранее, на мой взгляд, ограничение подхода one-jar-rules-them-all заключается в том, что нам сначала нужно создать код для каждой целевой платформы, где-то хранить двоичные файлы, а затем во время публикации в maven вытащить двоичные файлы оттуда и включить в последнюю банку. Я не знаю, как это сделать.

Когда дело доходит до нескольких модулей, это все еще не идеально, но решает эту проблему, а процесс сборки организован так, как я писал ранее.

Поэтому я могу предложить следовать предлагаемому мною подходу и разместить двоичные файлы в центре раньше, чем позже, и тогда, возможно, кто-то с лучшими знаниями maven сможет изменить его и сделать это лучше.

Как я писал ранее, на мой взгляд, ограничение подхода one-jar-rules-them-all заключается в том, что нам сначала нужно создать код для каждой целевой платформы, где-то хранить двоичные файлы, а затем во время публикации в maven вытащить двоичные файлы оттуда и включить в последнюю банку. Я не знаю, как это сделать.

Зачем где-то хранить двоичные файлы? как насчет того, чтобы поместить все собственные библиотеки на локальный диск (каталог ресурсов), включить их в банку при сборке и, наконец, опубликовать банку в maven?

Хорошо, так как бы вы это сделали? Кто-нибудь создает двоичные файлы для Windows, а затем отправляет их по электронной почте человеку с Linux?

Другой вопрос, я не понимаю ...

Почему для кросс-строительства нужно привлекать более одного человека? Трудно представить, чтобы процесс выпуска программы требовал двух человек ....

В rockdb они используют vagrant для кросс-сборки ubuntu и mac ... xgboost не имеет этих системных вызовов или чего-то еще, эти две платформы могут использовать один и тот же собственный файл lib в большинстве случаев ..

Для Windows я не эксперт в программировании win ... даже vargrant не работает, руководство внутри виртуальной машины достигнет той же цели

Следующий вопрос, который стоит обсудить: можем ли мы пропускать окна при выпуске на maven? Основная причина в том, что нам не хватает (нулевого?) Теста на xgboost4j под окнами ...

Что ж, нам, вероятно, не нужно привлекать более одного пользователя, но я тоже не эксперт в vargrant, извините.

Но то, что я предлагаю, требует трех пользователей:

• пользователь с Linux создает xgb и запускает mvn deploy . Это публикует только версию для Linux.
• пользователи с Windows и Mac создают xgb и запускают mvn --projects xgboost4j-native-windows deploy и mvn --projects xgboost4j-native-osx deploy соответственно.

Это для публикации версии моментального снимка, сборка релиза была бы немного сложнее, но я описал это выше. Поскольку я не знаком с vargrant и другими инструментами виртуализации, я не знаю, как это лучше организовать.

Сообщите мне, если мое предложение вас заинтересует, в противном случае я откладываю свои текущие усилия.

Я поговорю с ребятами из mxnet, чтобы понять, есть ли у них другие причины иметь много jar-ов в mvn central

Я успешно сделал банку с DLL Windows, Mac OSX macports dylib и Linux, и сохранил это в нашем артефакте, который работает очень хорошо. За исключением случаев, когда кто-то, кто использует brew, пытается использовать dylib macports, и он дает странную ошибку, не найденную библиотекой.

@alexeygrigorev Я с нетерпением жду возможности получить JAR-файл xgboost-spark для ОС Windows из центрального репозитория maven или других, я использую код в ОС Windows для инструментов IntelliJ IDEA ， затем запустите проект в производственной системе Linux, потому что это удобная отладка. По моему опыту, xgboost легко скомпилировать в ОС Linux, но в ОС Windows я никогда не добивался успеха. Так что, если вы это сделали, пожалуйста, скажите мне, большое вам спасибо.

У меня такая же проблема с @ Frank111 .

Пожалуйста, опубликуйте xgboost в Maven со встроенными собственными библиотеками для всех архитектур.

Даже для архитектуры, отличной от x86?

@CodingCat Да, для всех архитектур, поддерживаемых XGBoost4J.

Включите собственные библиотеки в пакет Maven и загрузите их во время выполнения в зависимости от того, какая архитектура приложения запущена.

Или, по крайней мере, разрешить выбор нативной архитектуры путем связывания с разными пакетами Maven во время сборки приложения (а не во время сборки вашей библиотеки!), Как это делает DeepLearning4J.

В любом случае сборка из исходников только для выбора многопоточности не требуется. И пакетов Maven должно хватить для использования библиотеки.

Я также был бы очень признателен, если бы хотя бы основные выпуски XGBoost4J были бы доступны через Maven.

Я также использую DeepLearning4J, который очень удобен в использовании по сравнению с XGBoost4J. Между тем dl4j даже предлагает ночные сборки на maven.

На мой взгляд, отсутствие надежных сборок XGBoost4J является серьезным препятствием для более серьезных случаев использования этой замечательной библиотеки. Создание XGBoost4J для Windows - тяжелое приключение;)

@mjakobus Да, я испытываю те же чувства: в XGBoost4J отсутствуют регулярные основные выпуски и особенно пакеты, выпущенные Maven, с выбранным внутренним интерфейсом во время выполнения.

Как люди используют это в производстве, если его нет в maven Central? Создавать файлы JAR вручную?

В Criteo мы создаем JAR-файлы XGBoost на Travis / Appveyor. Теоретически одни и те же скрипты можно повторно использовать для публикации официальных JAR-файлов для XGBoost, но у меня не было на это времени.

Мы просто вручную помещаем их в наш нексус
(Под "вручную" я подразумеваю через maven, но не с настройкой CI)

так что pom работает для создания артефакта с помощью стандартных команд сборки maven jar? И было ли это протестировано в среде Linux?

В нашем случае - да, и делаем это только для машин с linux

Я создал мультифабрикат с библиотеками Linux, Windows и Mac и поместил его в артефакт. Оттуда работает нормально.

В BlaBlaCar мы создаем его, а затем публикуем во внутренней сети. Затем приложения загружаются из нексуса. Это не multi-jar, поэтому у нас есть библиотеки для Linux и Mac отдельно. Затем приложения получают правильную зависимость, например, используя Os.isFamily(Os.FAMILY_MAC) . Хотя было бы здорово иметь сразу несколько банок. @Craigacp есть ли где-нибудь ваша

К сожалению, моя версия недоступна, но логика в XGBoost4J заставляет его загружать правильный двоичный файл на основе платформы, поэтому все, что вам нужно сделать, это распаковать каждую банку, скопировать dll, поэтому и dylib в тот же каталог ресурсов и перезапустить Это. Если вам требуется несколько версий Linux, этот подход не сработает, поскольку логика загрузки недостаточно сложна (аналогично это не удается, если у вас есть несколько файлов so для разных платформ, например Linux и Solaris).

@edumucelli, вы можете собрать мульти JAR, запустив отсюда download_latest_release.py .

Он построен для предположительно древней CentOS6, поэтому должен работать как с CentOS7, так и с более поздними дистрибутивами Linux.

@superbobry , это здорово! Спасибо, что поделились этим!

@alexeygrigorev @CodingCat @edumucelli, что из этого
Есть ли решение для автоматического создания JAR-файлов для xgboost и их публикации?

Есть, да. Прямо сейчас можно выполнить mvn publish, и он развернет его в вашем локальном репозитории nexus.

@Obarros Я использую мульти-JAR @superbobry для контейнеров на основе Debian в производственной

для всех, кто хочет использовать предварительно созданную версию xgboost, проверьте файл README в https://github.com/dmlc/xgboost/tree/master/jvm-packages , мы опубликовали артефакты в maven central

@CodingCat , @edumucelli Спасибо!

@CodingCat, не могли бы вы также подтолкнуть артефакты Windows? Опубликованный артефакт содержит только версию для Linux. Благодарность

@bluelu , он содержит как Linux, так и MacOS.

@edumucelli это обсуждалось в dmlc / xgboost # 3276. tl; dr @CodingCat решил не поддерживать Windows для Maven Central JAR.

У нас есть несколько готовых JAR-файлов в criteo-forks / xgboost-jars, которые, тем не менее, поставляются с Windows DLL.

Привет, это нормально для меня. Я создал свою собственную версию, но она наверняка поможет другим, если будет доступна без необходимости компилировать самостоятельно.

@superbobry, спасибо за ссылку на эту @bluelu о jar-файле только для Linux, который на самом деле также имеет dlyb для MacOS.