Git und Intellij und Encoding

Neulich™ hatte ich das Problem, dass ein UTF-8-enthaltender String falsch nach XML transformiert wurde. UTF-8 ist (? war es zumindest früher oft) so eine Sache in Java, man muss(te) an drölf Stellen das Encoding explizit setzen; dazu gehörten zB Stream, Writer/Reader, StringBuilder, etc pp. Das mag inzwischen anders sein, denn nach langem Debugging stellte sich raus, dass nur das File-Encoding in IntelliJ falsch gesetzt war – der Code funkionierte ohne Änderung, die Quelle des Strings war bereits fehlerhaft gespeichert. Irreführenderweise hatte der IntelliJ-Debugger den String die ganze Kette hindurch korrekt angezeigt. “Nimm IntelliJ” haben sie gesagt, “das funktioniert super” haben sie gesagt. m(

Wie dem auch sei: Da UTF-8 an der Stelle zwingend gefordert war, musste sichergestellt werden, dass kein Entwickler, aus welchen Gründen auch immer, ein anderes Encoding einschleust, bzw., wie in diesem Fall, UTF-8 durch falsch konfiguriertes Encoding kaputtspeichert. Ein Ansatz könnte sein, im Git-Repo UTF-8 zu erzwingen. Ein Ansatz dafür kann sein, das Encoding in einem Git-Hook zu prüfen. Anbieten tun sich pre-commit (der erste Hook, der greift; client-seitig; Beispiel [1] [2]) und pre-receive (der erste serverseitige Hook; Beispiel).

[Für Stash/Bitbucket Server scheint es auch Möglichkeiten zu geben; ein fertiges Plugin habe ich aber nicht gefunden.]

pre-commit hat den Vorteil, dass sich keine Commits aufstauen, bevor das Problem auffällt. Dafür müssen lokale Hooks aufwändig verteilt/aktiviert werden – bsplw. über separat eingecheckte Verzeichnisse, die gesymlinkt (aber was ist mit Windows? Was mit wirklich lokalen Hooks? Und was ist noch zu beachten?) oder kopiert werden. Für pre-receive gelten Vor- und Nachteile inversiert, außerdem benötigt man Zugriff auf den Server auf Dateisystemebene.

Lange Rede, kurzer Sinn: Aus Gründen haben wir uns für einen pre-commit entschieden. Das Skript muss dabei .git/hooks/pre-commit heißen. Ich hätte ein Verzeichnis pre-commit mit Skripten darin erwartet, aber das wirft einen

cannot spawn .git/hooks/pre-commit: No such file or directory

Und es war gar nicht so einfach, eine Datei überhaupt mit dem falschen Encoding abzuspeichern. Sublime und Notepad++ haben sich (stillschweigend, was Notepad++ angeht) geweigert. Schließlich habe ich es mit IntelliJ geschafft, was allerdings auch gewarnt hat. Keine Ahnung, wie das ursprüngliche Problem überhaupt zustande kam.

Lokale Kopie des Skripts:

[Achtung: Das Skript kann nicht mit Binaries umgehen! Und das schließt bereits .woff ein. Offenbar ist es auch nicht trivial, Binaries zu erkennen; Internet nutzt dazu die Dateigröße oder auch Fileextensions. Ersteres scheint mir unzuverlässig, man denke an kleine Grafiken. Zweiteres ist sehr aufwändig…]

Beispielhafte Ausgabe (“ISO 8859-1.txt” heißt die Datei):

Und, der Vollständigkeit halber: Die Einstellung von Intellij:

btw: In Eclipse kann man Settings als Textfile exportieren und bsplw. in einem Repo ablegen – in IntelliJ scheint das nur als .jar exportierbar zu sein, bzw. über einen “IntelliJ Configuration Server” (WTF!?) verteilbar?

Eclipse: JPDA Port (nachträglich) herausfinden

Ich habe einige Play-Anwendungen im Terminal laufen, plus einer weiteren in Eclipse. Die in Eclipse würde ich gerne debuggen, wozu play eclipsify einen entsprechenden Launcher “Connect JPDA to myapp.launch” anlegt. Der Launcher enthält einen Port “0”:

Nun ist der Port (ich glaube, “0” wählt den default 8000, aber das kann falsch sein) nicht erreichbar, vielleicht ist er durch die Anwendungen im Terminal belegt. Vielleicht wählt “0” auch jedes mal einen zufälligen Port, ich kann das gerade nicht gegenprüfen. Wie auch immer, der Punkt ist:

Beim Start der Anwendung gibt es eine Ausgabe im Log à la

Listening for transport dt_socket at address: <port number>

Läuft die Anwendung lange genug, sehe ich diese Ausgabe aber nicht mehr – wie finde ich nun den Port heraus? Unter OS X wie folgt: Zuerst suche ich in der Aktivitätsanzeige alle “java”-Prozesse:

Uns interessiert derjenige, der zu Eclipse gehört (diese Ansicht wird per Doppelklick auf den Prozessnamen geöffnet):

Die Liste der “geöffneten Dateien und Ports” ist recht lang, aber der Eintrag sticht durch seine Kürze hervor: Voilà, der gesuchte Port.

PS: Man kann den Logger von Play natürlich auch so konfigurieren, dass es die Ausgabe in ein File schreibt, siehe hier (via). Hier brauchte ich aber die Möglichkeit den Port herauszufinden, ohne die Applikation neu zu starten.

Slightly related: Den Prozess, der auf Port (z.B.) 80 hört, findet sich per

” -t” listet die Prozesse auf (Quelle), um sie an kill übergeben zu können:

sudo kann optional sein.

Maven: Sourcen runterladen

Ein Projekt für die IDE aufbereiten geht bekanntermaßen (hier für Eclipse) über

Mit dem kleinen Parameter -DdownloadSources werden dabei auch die Sourcen geladen:

Das funktioniert auch nachträglich, die Projekt-Datei wird dann neu geschrieben. Eventuell ist dann ein Refresh nötig.

In dem Zusammenhang: Es gibt eine zentrale Suche für Maven: http://search.maven.org/

FDT 5: Debugger per Ant starten [UPDATE]

Bevor ich das zum einhundertundelfzigsten mal suchen muss:

Analog dazu: Der Profiler

UPDATE: Eine CoreException wie

org.eclipse.core.runtime.CoreException: could not build project

kann man mittels Project->clean beheben; ein

BUILD FAILED
/xxx/yyy/zzz/build/build.xml:123: java.lang.NullPointerException

liegt vermutlich an der Flex-Version. Ich habe das erfolgreich für einige Versionen unter 4.6 getestet, für 4.6 muss man die flex-sdk-description.xml ändern.

Validation in Eclipse [UPDATE]

Wer JS-Error angezeigt bekommt, obwohl er schon sämtliche Validatoren deaktiviert hat, der gehe zu

Projekt Einstellungen -> JavaScript -> Include Path -> Source

und gebe unter “Included” ein “_” ein (einfach damit da was steht), unter “Exluded” gebe man “.*” an (quasi via).

Ein

invalid content was found starting with element…

für WSDLs löst man angeblich mit dem Entfernen des Häkchens unter

Eclipse Einstellungen -> XML -> XML Files -> Validation -> Honour all XML schema locations

…bei mir hat das geholfen, allerdings kommen die Fehler auch nicht zurück, wenn ich das Häkchen wieder setze. Eclipse halt. Und: Ja, ich finde es auch komisch, dass hier offenbar XMLs und WSDLs vermischt werden 🙂

Build-File- (Ant-) Probleme lassen sich über

Einstellungen -> Ant -> Editor -> Problems

justieren

Ein

Errors occurred during the build.
Errors running builder ‘JavaScript Validator’ on project ‘some-project’.
java.lang.NullPointerException

lässt sich in Project->Properties->Builders unter “Javascript Validator” deaktivieren.

tbc

Probleme mit dem Tomcat in eclipse

Wer eine java.io.EOFException (“IOException while loading persisted sessions “) bekommt, der möge alles in

“your workspace”/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/work

löschen (via) – manchmal ist “work” auf in “tmp1”, … zu finden.

Wessen Tomcat ein “May be locked by another process” bekommt, der möge

“your workspace”/.metadata/.lock

löschen. Was man tun kann, wenn das trotzdem bei jedem Neustart wieder auftritt, weiß ich auch nicht.

Wann hat eclipse eigentlich angefangen, nicht mehr zu funktionieren?