Sbt-github-packages: Пакеты GitHub, похоже, не поддерживают sbt (пока)

Насколько я могу судить, -sources, -javadoc, -tests не поддерживаются

используя sbt-aether-deploy, я успешно опубликовал на github пакеты из sbt

проект /plugins.sbt

addSbtPlugin("no.arktekk.sbt" % "aether-deploy" % "0.23.0")
addSbtPlugin("com.dwijnand" % "sbt-dynver" % "4.0.0")

build.sbt

externalResolvers += "GitHub lokkju Apache Maven Packages" at "https://maven.pkg.github.com/lokkju/github-action-sbt"
publishTo := Some("GitHub lokkju Apache Maven Packages" at "https://maven.pkg.github.com/lokkju/github-action-sbt")
credentials += Credentials("GitHub Package Registry", "maven.pkg.github.com", "lokkju", "<GITHUB_TOKEN>")

// GitHub package repo isn't supporting javadoc and sources
publishArtifact in (Compile, packageDoc) := false
publishArtifact in (Compile, packageSrc) := false

sbt aetherDeploy

Дополнительный аспект; если я использую Charles Web Debugging Proxy, все работает нормально. Без него я иногда получаю ошибки о том, что сервер не отвечает.

@lokkju Хм, а как насчет многомодульных сборок?

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

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

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

Я обнаружил, что просто использую curl, чтобы попытаться загрузить пакеты;

• Первый файл, который вы РАЗМЕЩАЕТЕ, рассматривается как основной артефакт, независимо от имени файла или расширения.
• затем вы можете загрузить столько (действительных) файлов POM, сколько захотите, если они имеют уникальные имена.
• вы не можете загружать любые другие файлы, отличные от POM
• Файлы с расширениями файлов JAR и POM анализируются github, и недопустимые форматы сообщают об ошибке в виде возвращаемого сообщения об ошибке HTTP 4xx.

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

У меня есть электронное письмо в службу поддержки, посмотрим, предоставят ли они дополнительную информацию.

Хм, значит, никакой подписи артефактов тоже нет?

Он автоматически генерирует *.md5 и *.sha1 для любых загружаемых файлов.

Также нашел это: https://github.com/sbt/librarymanagement/blob/d09f9f81b664baaac15054730fbcb51e1b240de2/ivy/src/main/scala/sbt/internal/librarymanagement/IvyActions.scala#L123

Artifactory deals with the publishing (and republishing) of SNAPSHOTs using a strict rule on the order of publishing. The ;build.timestamp=... suffix is the alternative.

The strict rule is:

publish the main artefact (which has no classifier)
publish the POM/ivy.xml file
publish additional artefacts which have a classifier

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

Я, вероятно, создам чистый проект maven/java и посмотрю, работает ли он тогда.

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

[error] stack trace is suppressed; run last publish for the full output
[error] (publish) java.io.IOException: PUT operation to URL https://maven.pkg.github.com/company/foo/bar/utils/3.24.0-SNAPSHOT/utils-3.24.0-SNAPSHOT.pom failed with status code 400: Bad Request

Нет упоминания о моментальных снимках в документах

На самом деле у меня то же самое для обычных пакетов:

java.io.IOException: PUT operation to URL https://maven.pkg.github.com/company/foo/bar/utils/utils/0.0.1/utils-0.0.1.pom failed with status code 400: Bad Request

[error] java.io.IOException: PUT operation to URL https://maven.pkg.github.com/company/foo/bar/utils/utils/0.0.1/utils-0.0.1.pom failed with status code 400: Bad Request
[error]     at org.apache.ivy.util.url.AbstractURLHandler.validatePutStatusCode(AbstractURLHandler.java:82)
[error]     at org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:264)
[error]     at org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
[error]     at org.apache.ivy.util.FileUtil.copy(FileUtil.java:150)

Интересно, как выглядит корпус этого 400-го?

Есть ли обновления по этому поводу?

Обновлений пока нет! Думаю, эксперименты @lokkju — самые свежие. Я хочу поиграть с этим еще немного, но, честно говоря, похоже, что пакеты GitHub по-прежнему не поддерживают файлы хостинга, которые являются неотъемлемой частью стандартного дистрибутива Maven (такие как подписи, документация и классификаторы). Трудно сделать с ним что-то практичное в качестве хоста артефакта, пока они не исправят эти недостатки.

Еще немного информации, тестирование с простым sbt 1.3.2 (без дополнительных плагинов)

Вам необходимо опубликовать в репозиторий вашего проекта:

publishTo := Some("GitHub Package Registry" at "https://maven.pkg.github.com/[username]/[project]")

учетные данные должны быть определены следующим образом

credentials += Credentials("GitHub Package Registry","maven.pkg.github.com","[username]","[token]")

Вашему токену нужны следующие области видимости: read:packages , repo и write:packages

но как только вы опубликуете, вы получите эти предлагаемые координаты пакета (где организация = "io.test" и name = "test"):

<dependency>
  <groupId>com.github.[username]/[project]</groupId>
  <artifactId>io.test.test_2.13</artifactId>
  <version>0.1</version>
</dependency> 

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

Загрузка Pom работает, но остальное не работает:

[информация] опубликовала test_2.13 на https://maven.pkg.github.com/ [имя пользователя]/[проект]/io/test/test_2.13/0.0.3/test_2.13-0.0.3.pom
[ошибка] java.io.IOException: доступ к URL-адресу https://maven.pkg.github.com/ [имя пользователя]/[проект]/io/test/test_2.13/0.0.3/test_2.13-0.0. 3.jar был отклонен сервером: Запрещенный ответ=Ошибка: "test_2.13-0.0.3.jar" в версии 0.0.3 "io.test.test_2.13" уже опубликован.

Загрузка JAR @francisdb не удалась, потому что SBT загружает файлы не по порядку; насколько я помню, это давняя ошибка в SBT (IvyActions.scala), когда функция публикации использует тип карты вместо типа seq. С переходом на систему управления зависимостями Coursier эта проблема может разрешиться сама собой.

Мое предложение состояло бы в том, чтобы переопределить сам процесс загрузки в этом плагине, предварительно загрузив pom. Конечно, это все еще не помогает с классификаторами, для которых мне нужна поддержка.

похоже на sbt 1.3.2 Coursier не используется для загрузки артефактов, только для загрузки

Кроме того, я не получил ответа от GitHub по этому вопросу.

Хм... Я только что бегло просмотрел. sbt 1.2.8 все еще используется здесь везде:
https://github.com/djspiewak/sbt-github-packages/blob/0839b97dea06100a202f2a105cbe83873784bf77/build.sbt#L28
https://github.com/djspiewak/sbt-github-packages/blob/0839b97dea06100a202f2a105cbe83873784bf77/src/sbt-test/sbtghpackages/publish/project/build.properties#L1
https://github.com/djspiewak/sbt-github-packages/blob/0839b97dea06100a202f2a105cbe83873784bf77/project/build.properties#L1

(Возможно, что-то пропустил)

Я предполагаю, что они нуждаются в обновлениях?

Пулл-реквест: #2

Coursier используется только по умолчанию, начиная с sbt 1.3.0.

мое тестирование было с 1.3.2

@francisdb Понял.

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

[info]  published test_2.13 to https://maven.pkg.github.com/francisdb/foo/com/example/test_2.13/0.0.9/test_2.13-0.0.9.pom
[info]  published test_2.13 to https://maven.pkg.github.com/francisdb/foo/com/example/test_2.13/0.0.9/test_2.13-0.0.9.jar
[info]  published test_2.13 to https://maven.pkg.github.com/francisdb/foo/com/example/test_2.13/0.0.9/test_2.13-0.0.9-sources.jar
[info]  published test_2.13 to https://maven.pkg.github.com/francisdb/foo/com/example/test_2.13/0.0.9/test_2.13-0.0.9-javadoc.jar

Веб-интерфейс все еще смущен суффиксом sbt

<dependency>
  <groupId>com.example.test_2</groupId>
  <artifactId>13</artifactId>
  <version>0.0.9</version>
</dependency> 

Это впечатляет! Я собираюсь провести некоторые тесты сегодня и посмотреть, смогу ли я закрыть это. Очень очень интересно.

Я могу подтвердить, что с несколькими настройками плагина для использования экспериментальных результатов @francisdb все теперь работает! Проблемы веб-интерфейса с суффиксами кросс-сборки, по-видимому, не влияют на фактическое разрешение, а только на пользовательский интерфейс. Итак, публикация и разрешение теперь работают с плагином. Я еще не тестировал вещи с частным репозиторием; я предполагаю, что они еще не совсем работают, но все достаточно хорошо, чтобы я опубликовал 0.1.0 .

Спасибо всем за ваш труд и эксперименты! Плагин удивительно тривиален благодаря всем вам.

@francisdb

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

Вы _можете_ загружать их дважды: вы можете удалить снимок в пользовательском интерфейсе GitHub, а затем снова загрузить новый снимок (имеется в виду та же версия снимка). Это сработало для меня. Немного громоздко, но работает.