Szerezze be az sbt első letöltését a proxyn keresztül

Az sbt-nek szüksége lehet a hálózatra, mielőtt a build-definíciója bármi hasznosat tenne. A launcherének be kell szereznie a komponenseket, a build pedig később további könyvtárakon keresztül érheti el a tárolókat. Egy feladaton belül elrejtett proxy-beállítás túl későn érkezhet az első letöltéshez.

Kezdje azzal a JVM-mel, amely valóban futtatja az sbt-t. Egy olyan launcher esetében, amely a projekt .jvmopts fájlját olvassa, az alapvető végpont-tulajdonságok ezek lehetnek:

-Dhttp.proxyHost=proxy.example.net
-Dhttp.proxyPort=8080
-Dhttps.proxyHost=proxy.example.net
-Dhttps.proxyPort=8080

Ezek az értékek különválasztják a hosztnevet és a portot; nem teljes proxy URL-ek. Az engedélyezett nyilvános tároló-letöltésekhez a HTTP proxy lista jelölt értékeket kínál ezekhez a mezőkhöz. Egy HTTPS-tároló továbbra is elérhető HTTP proxyn keresztül, CONNECT használatával.

Figyelje meg, melyik letöltés hibázott

A launcher bootstrapje, a build-eszköz komponensei, a bővítmények és a függőségek nem feltétlenül ugyanazt a konfigurációs réteget használják. A tárolódeklarációk szerkesztése előtt azonosítsa a hibázó URL-t és szakaszt.

A tároló kiválasztása arra válaszol, honnan származnak az artefaktumok. A proxy konfigurációja arra válaszol, hogyan éri el egy hálózati kliens azt a végpontot. Egy tároló belső tükörrel való helyettesítése külön támogatott választás lehet, de nem konfigurál hálózati proxyt minden más célhoz.

A proxy-hitelesítés egy újabb ellenőrzés. Ne feltételezze, hogy minden Java-letöltő egy tetszőleges proxyUser tulajdonságot támogatott bejelentkezési mechanizmusként kezel. Használja a telepített launcherhez és a vonatkozó feloldóhoz dokumentált hitelesítési elrendezést.

Végül ellenőrizze a launcher tényleges környezetét, ahelyett hogy egy másik futtatóhoz írt útmutatóból másolna egy változót. A DNS-hiba, az elérhetetlen tároló és az elutasított proxy-bejelentkezés mind megjelenhet a függőségek feloldása során, mégis nagyon eltérő javításokat igényelnek.