Не удалось загрузить SBT из-за корпоративного прокси-сервера Artifactory Pro - PullRequest
1 голос
/ 30 мая 2019

Я сконфигурировал файл локальных репозиториев ~/.sbt/repositories следующим образом:

[repositories]
local
my-ivy-proxy-releases: http://ourinternalartifactoryaddress.com/artifactory/scala-ivy/, [organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]
my-maven-proxy-releases: http://ourinternalartifactoryaddress.com/artifactory/mvn-all

Разрешение виртуального репозитория mvn-all, похоже, работает хорошо - это прокси-сервер maven-central, а также числовнутреннего стандарта мавен репо.Разрешение от scala-ivy (виртуальное репо) хорошо работает для удаленного репозитория sbt-plugins, но не работает для разрешения таких вещей, как сам SBT.

Настройка

scala-ivy - виртуальное репо (тип пакета Ivy) с 3 удаленными репозиториями:

  1. maven-central-mirror - (http://central.maven.org/maven2) `, здесь sbt должен загружать себя из пакета типа 'Maven'
  2. typesafe-ivy-releases - репозиторий jcenter (https://dl.bintray.com/typesafe/ivy-releases/), в котором находятся версии sbt до строки 1.x и ряд артефактов Scala,тип пакета 'Ivy'
  3. scala-sbt - (https://repo.scala -sbt.org / scalasbt / sbt-plugin-Releases / ), тип пакета 'SBT'

Вопрос - что не так с этой настройкой / чего мне не хватает при загрузке?

1 Ответ

0 голосов
/ 31 мая 2019

Я не уверен, что это оказалось временной проблемой, но сегодня утром был удивлен, когда SBT загружал себя из нашего mvn-all виртуального репозитория в Artifactory, когда исторически SBT находился в репозитории Ivy.

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

...