SBT Resolvers überschreiben

In SBT gibt es die Möglichkeit resolvers und externalResolvers zu überschreiben. Auch wenn dies geschieht, werden immer vorher die Typesafe-Mirrors (die leider relativ langsam sind) verwendet. Weiters kann es vorkommen, dass ein Zugriff auf Artefakte nur über einen internen Proxy (Nexus, Artifactory,…) möglich ist.

Um das Problem zu lösen, müssen die fullResolvers überschrieben werden. Vor den gewünschten Repositories müssen projectResolver und otherResolvers verwendet werden.

In der build.sbt wird dazu folgender Eintrag ergänzt:

1
2
3
4
5
6

resolvers := Seq(
  "maven-proxy" at "https://your.artifactory/maven-proxy/",
  Resolver.url("ivy-proxy", url("https://your.artifactory/ivy-proxy/"))(Resolver.ivyStylePatterns)
)

fullResolvers := Seq(projectResolver.value) ++ otherResolvers.value ++ resolvers.value

Für mehrere Repositories bzw. bessere Lesbarkeit können für die Repository-Deklarationen auch Hilfsmethoden geschrieben werden, z.B.:

1
2
3
4
5
6
7
8
9

def maven(repoName: String, repoUrl: String): MavenRepository = repoName at repoUrl
def ivy(repoName: String, repoUrl: String): URLRepository = Resolver.url(repoName, url(repoUrl))(Resolver.ivyStylePatterns)

resolvers := Seq(
  maven("maven-proxy", "https://your.artifactory/maven-proxy/"),
  ivy("ivy-proxy", "https://your.artifactory/ivy-proxy/")
)

fullResolvers := Seq(projectResolver.value) ++ otherResolvers.value ++ resolvers.value

Änderung für alle SBT-Projekte auf dem lokalen PC

Um diese Änderung für SBT auf dem lokalen PC für alle Projekte zu übernehmen, muss das gleiche in der ~/.sbt/0.13/global.sbt hinzugefügt werden.

Konfiguration für Play-Projekte

Proxy-Repository

Für Play müssen auf dem Proxy zusätzlich zu den Standard-Maven-Repositories (https://repo1.maven.org/maven2) folgende Repositories konfiguriert werden:

maven-proxy (Maven Repository)

ivy-proxy (Ivy Repository)

Play-Projekt

Die Änderung der Resolver muss in der build.sbt sowie in der project/plugins.sbt vorgenommen werden, um diese für beide Builds zu aktivieren.

Getestet mit einem Play 2.5 Scala Projekt.

Docker als non-root User unter Fedora

Um Docker als nicht-root Benutzer unter Fedora verwenden zu können, muss der Benutzer zur Gruppe dockerroot hinzugefügt und in die Datei /etc/sysconfig/docker zur OPTIONS-Variable -G dockerroot hinzugefügt werden.

Die Gruppe dockerroot wird bei der Installation erstellt.

Fedora 21 Docker 1.5.0

Kommentar von Felix Becker am 2015-07-05 20:38:15

Sollte man nicht tun. Ein docker run --privileged kann erheblichen Schaden damit anrichten - das wäre analog zu sudo mit NOPASSWD: ALL.
Dann lieber alias docker="sudo docker".

Play bei LinkedIn - Cooles Video

Habe gerade bei Youtube einen Jax-Talk zum Einsatz des Playframeworks bei LinkedIn gesehen. Das Async-Handling von Play ist wirklich absolut genial:

nginx IPv6: Cannot assign requested address

Ich hatte gerade das Problem, dass mein nginx beim Booten nicht gestartet hat, direkt danach hat das starten aber mit ssh problemlos funktioniert.
Nachdem ich das “2> /dev/null” im init-script entfernt hab, hab ich dann beim Booten endlich den Grund dafür gesehen:

nginx: [emerg] bind() to [2a01:4f8:201:910b:500::100]:80 failed (99: Cannot assign requested address)

Das kommt daher, weil ich für verschiedene vHosts eigene IPv6-Adressen konfiguriert hab, also auf jeder IPv6-Adresse läuft nur ein vHost. Das erklärt jetzt auch, wieso ich das Problem auf einem anderen Server nicht hab, weil da überall [::] konfiguriert ist.

Die Ursache für das Problem ist aber, dass direkt nach dem hinzufügen einer IP-Adresse diese noch im ’tentative state’ ist, und deswegen nginx noch nicht drauf binden kann. Deswegen hab ich jetzt unter Debian in die /etc/network/interfaces beim inet6 Block folgendes hinzugefügt:

post-up echo -n "waiting for IPv6 addresses "; while ip -6 addr show tentative | grep . > /dev/null ; do echo -n "."; sleep 0.2 ; done; echo

Damit wartet er, bis alle IPv6-Adressen verfügbar sind, und nginx kann normal starten.

Gentoo - Chromium - kaputte Fonts

Ich habe seit einiger Zeit Probleme mit Chromium auf Gentoo und der Fontdarstellung.

Die Fonts “Verdana, Helvetica, Arial, sans-serif” (CSS) sahen in normaler Textgröße super aus, sobald aber die Font größer war (z.B. 20px font size), war die Font pixelig und verwaschen.

Um das Problem zu lösen, habe ich mir das Corefonts-Package mit

emerge media-fonts/corefonts

merged. Seit der Installation sehen auch alle Schriften in größerer Version wieder sauber aus.

Ich muss noch mal debuggen, wie der Font-Loading-Mechanismus vom Chrome funktioniert um zu sehen, welche Schriftarten vorher die Übeltäter waren.