5

Seit dem letzten Freitag benötigen meine Play Framework-Apps aufgrund von extrem langen Zeiten, die Abhängigkeiten auflösen, mehr als 15 Minuten zum Kompilieren.Play Framework benötigt extrem lange Zeit, um Abhängigkeiten aufzulösen

Die Abhängigkeiten liegen auf repo.typesafe.com, repo1.maven.org und einigen anderen, einschließlich Deadbolt, gehostet auf GitHub Pages (http://schaloner.github.com), also bin ich mir nicht sicher, dass es sich um ein einziges externes handelt Repo.

Ich kann nicht für das Leben von mir herauszufinden, was das verursacht. Kann mir jemand eine Idee geben, wo ich mit der Fehlersuche beginnen kann?

EDIT: Weitere Info - Ich habe ein neues Play-App mit einer neuen Play-Instanz auf eine neue virtuelle Maschine (Ubuntu 12.04) getestet und ich bekomme die gleichen langen Lösungszeiten für das Hinzufügen des mysql jdbc Anschlusses von Maven 1 und Deadbolt von GitHub Pages. Es scheint, als würde es an einem der Repos hängen und nicht das Zeitlimit überschreiten, aber ich weiß nicht, wie ich herausfinden soll. Ich habe den TypeSafe-Repo in der Datei plugins.sbt auskommentiert, aber das Problem besteht weiterhin. Zieh mir jetzt die Haare aus.

EDIT 2: Fehler existiert in 2.0 und 2.1 Filialen. Kann nicht in 2.2 repliziert werden. Im Moment sieht es so aus, als würde man die publizierten Dateien zu [Play directory]/repository/cache hinzufügen. Stoppe Versuche, jedes Mal alles zu lösen.

+0

habe ich das gleiche Problem . – stys

+0

Ändern Sie die Protokollstufe in Projekt/plugins.sbt auf "Warnen". 'logLevel: = Level.Warn' – Adil

+0

@Adil Alle Projekte haben bereits diese Log-Ebene gesetzt. – evanjdooner

Antwort

1

Ich denke, dass das Problem durch Ausfallzeiten bei Github verursacht wird. Mein Projekt ist abhängig von Github gehosteten Projekten wie Deadbolt, und so habe ich entsprechenden Repositories meine Build.scala

resolvers += Resolver.url("Objectify Play Repository (release)", url("http://schaloner.github.com/releases/"))(Resolver.ivyStylePatterns), 
resolvers += Resolver.url("Objectify Play Repository (snapshot)", url("http://schaloner.github.com/snapshots/"))(Resolver.ivyStylePatterns) 

Datei hinzugefügt, was ich habe bemerkt, dass Wiedergabe attemps meine andere Abhängigkeiten durch dieses Repository zu lösen. Zum Beispiel habe ich gesehen, dass Timeout-Fehler apache.commons-io und htmlunit und ihre transitiven Abhängigkeiten im von Github gehosteten Repository des Deadbolts auflösen. Im Normalfall würden solche Versuche schnell fehlschlagen. Aber wenn Github langsam ist, dauert es sehr lange, um eine Fehlerreaktion zu erhalten.

Es sollte eine Möglichkeit geben, genauer festzulegen, welches Repository für jede Abhängigkeit verwendet werden soll, aber ich bin mir nicht sicher, wie man das mit SBT oder Maven macht.

UPDATE

Das Problem nicht behoben wurde. Hier ist ein Beispiel für Timeout-Fehler, diesmal auf Typesafe-Repository

[error] Server access Error: Connection timed out: connect url=http://repo.types 
afe.com/typesafe/releases/org/apache/commons/commons-email/1.2/commons-email-1.2 
.jar 

UPDATE 2

Ein sehr ähnliches Problem gesehen wurde:

https://groups.google.com/forum/#!msg/play-framework/cBIkLb_WPN8/uuJIdhdtvtEJ

+0

Das habe ich mir überlegt. Ich dachte, es hätte etwas mit Fehlern in einem der entfernten Repos zu tun. Meine Tests wurden mit neuen Play-Installationen und neuen Projekten durchgeführt, wobei nur die Abhängigkeit mysql-connector-java von Maven 1 und keine benutzerdefinierten Resolver verwendet wurden.Ich habe lange mit Play 2.0.X und 2.1.X, aber nicht mit 2.2.X gesehen. Wir haben ein Upgrade auf 2.2.2 durchgeführt, und damit ist das Problem jetzt gelöst. – evanjdooner

+1

Da wir zu 2.2.2 gewechselt haben, hatten wir keine Probleme. Ich kann bestätigen, dass das Problem immer noch auf 2.1.5 ab Di 22 Apr 2014 – evanjdooner

+1

@evanjdooner Vielen Dank für das Update. Ich überlege, zu 2.2.2 zu wechseln, was einige Anstrengungen erfordern würde. Momentan verwende ich eine schnelle Abhilfe. Beim ersten Build nach dem Löschen entferne ich manuell Github-basierte Repositories von Build.scala. Dadurch können andere Abhängigkeiten schnell aufgelöst und zwischengespeichert werden. Dann lege ich entfernte Teile und baue das zweite Mal. – stys