Ich versuche, mit Cargo von Maven über https auf einem entfernten Tomcat7 zu deployen.
Ich habe die Manager-Skript-Rolle eingerichtet, und ich war so weit, dass ich eine App remote bereitstellen konnte.
Was ich habe, sieht so aus:
%Vor%Nun, ich kenne die Anmeldeinformationen und alles ist korrekt eingerichtet, und ich habe die neue / Text-Schnittstelle verwendet, und ich konnte eine bestehende App deimplementieren. Aber wenn Sie versuchen, deploy auszuführen:
%Vor%Ich bekomme einen Fehler mit der Ursache:
%Vor%Ich verstehe es sofort, also kann es kein Timeout sein.
Kann die Datei zu groß sein? Es ist ein 60 MB Krieg. Ich habe dafür gesorgt, dass mein Nginx größer ist:
%Vor%Ich habe auch multipart config zum text manager in der manager webapps web.xml wie folgt hinzugefügt:
Servlet & gt; Manager org.apache.catalina.manager.ManagerServlet debuggen 2
%Vor%
Ich liebe Maven in vielerlei Hinsicht, aber die Fehlerberichterstattung ist wirklich schrecklich. Jede Hilfe sehr geschätzt.
Ich wurde kürzlich von diesem Fehler gebissen, als ich cargo:deploy ein Artefakt versuchte. In der Regel stoppen, bereinigen und starten Sie das Verzeichnis webapps vor der Bereitstellung. Dieses Mal wurde jedoch festgestellt, dass ein Artefakt nicht entfernt wurde.
Nach dem Wechsel zu cargo:redeploy wurde der Fehler behoben.
Bei der Bereitstellung auf einem tomcat 8-Server mit der ant-deploy-Aufgabe bin ich auf dieselbe Fehlermeldung gestoßen. Das Problem in meinem Fall war, dass mir der Speicherplatz auf dem Server knapp wurde. Überprüfen, Tomcat Manager-Protokoll ist, was mich in:
%Vor%Ich erinnere mich nicht, ob oder wie ich das gelöst habe, aber da Rascio das gleiche Problem hat, werde ich eine Idee veröffentlichen. Vielleicht ist es die Wagen-Erweiterung für ssl, die benötigt wird:
%Vor%Aber natürlich. Ich denke du hast es vor Maven 3.0 nicht gebraucht.
Ein weiterer Grund für diese Ausnahme, auf die wir am Montag plötzlich gestoßen sind, als die Deployment-Jobs auf unserer Jenkins Instanz mit dem Plugin cargo plugin nicht mehr funktionieren. Nicht alle, aber einige. Der Hauptunterschied war eine benutzerdefinierte settings.xml in den Aufträgen für ein Nexus -Repository, von dem Deployables heruntergeladen werden konnten .
Die erfolgreichen Bereitstellungsjobs wurden wie in Ссылка beschrieben konfiguriert Bei den fehlgeschlagenen fehlten die repository und pluginRepository
Ich bin mir immer noch nicht sicher, warum sich das Verhalten an einem Punkt geändert hat. Irgendwelche Tipps?
Tags und Links tomcat7 maven-cargo