GIT zwischen Windows und Linux

[Z_E_R_O]

Moin,

ich habe ein Java Projekt(Maven) in Visual Studio Code auf Windows begonnen und würde auch gerne an meiner Linux Maschine weitercoden. Dazu habe ich ein GIT Remote-Repository aufgesetzt und das funktioniert auch mit dem Pullen und Pushen zwischen Windows-Maschinen. Wenn ich aber den Code auf meine Linux-Maschine pulle oder klone, dann hat der Code viele Fehler.

Erst dachte ich, dass es an der java Version liegt, aber das anpassen des JDK hat nichts gebracht.
Dennoch befürchte ich, dass Linux hier etwas spinnt, weil wenn ich im Terminal z.B. nach $JAVA_HOME frage kommt eine leere Ausgabe. Erst wenn ich eine Datei source in der der Befehl "export JAVA_HOME=/usr/lib/jvm/jdk-16.0.2/" getätigt wird, spuckt er den Pfad im Terminal aus. VSC ist allerdings auf die richtige Java-Version konfiguriert.

x@debian:~$ java -version openjdk version "16.0.2" 2021-07-20 OpenJDK Runtime Environment (build 16.0.2+7-67) OpenJDK 64-Bit Server VM (build 16.0.2+7-67, mixed mode, sharing) x@debian:~$ echo $JAVA_HOME x@debian:~$ echo $PATH /usr/lib/jvm/jdk-16.0.2//bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games x@debian:~$ source /etc/environment x@debian:~$ echo $JAVA_HOME /usr/lib/jvm/jdk-16.0.2/

Fehler sind in der Regel sowas wie,
{ "resource": "/Programmieren/stream/src/main/java/com/example/stream/api/v1/errorHandlers/CustomExceptionHandler.java", "owner": "_generated_diagnostic_collection_name_#1", "code": "67108964", "severity": 8, "message": "The method builder() is undefined for the type Error", "source": "Java", "startLineNumber": 29, "startColumn": 29, "endLineNumber": 29, "endColumn": 36 }

oder, dass etwas nicht initialisiert ist. Und das zuhauf. Aber unter Windows läuft es genau so.
Gibts da irgendeinen Trick, oder muss man auf etwas bestimmtes achten, wenn man sowohl auf Windows und Linux arbeiten will?

 

[PHuV]

Zeilentrenner Problematik?
0d0a (newline, carriage return) Windows und 0a Linux. Das führt zu Problemen. Man kann es aber in den meisten Git-Clients einstellen, was als Zeilentrenner verwendet werden soll.

 

[BeBur]

Klingt grad eher wie nicht/falsch konfigurierte Umgebungen/Betriebssysteme. Ka wie VSC das im Detail löst aber es verwendet offenbar auch die Pfade/Konfigs des OS mit.

Unklar ist, ob es gereicht hat, JAVA_HOME zu setzen. In dem Fall Google einfach danach, wie das automatisch geht bei Windows/Linux (.bashrc).

 

[PHuV]

JAVA_HOME sollte man tunlichst immer selbst gut dafür sorgen, daß es gesetzt wird.

 

[Z_E_R_O]

@PHuV Das schaue ich mir mal an.
@BeBur Alles was Google hergibt habe ich schon durch. Eben auch nochmal den export für die JAVA_HOME Variable in .bashrc geschrieben. Fehler sind immer noch da, allerdings wird der Pfad jetzt im Terminal angezeigt. Mal sehen, ob das nach nem Neustart immer noch so ist.

 

[PHuV]

Wenn Du die /etc/.bashrc meinst, erst mal Vorsicht, nicht jedes Linux nimmt das auch so. Und man muß seine Session in dem Moment erneuern, oder vorher mit source /etc/.bashrc in der laufenden Session neu einlesen. 1.Vorsicht, damit ist aber die Java Umgebung immer nur in Deiner laufenden Session aktiv. 2.Vorsicht, Systemprozesse wie Systemd und init.d brauchte die Umgebung immer separat in den Startscripten, ebenso wenn Du mit anderen Benutzern Scripte startest.

Daher ja mein Tipp, immer selbst dafür sorgen, das die korrekte Java Umgebung gesetzt ist, in jedem Script bzw. Ausführung und Umgebung. In manchen Fällen ist es sogar sinnvoll, vorher die Java-Umgebung zu prüfen und danach zu suchen.

 

[Z_E_R_O]

@PHuV
Also ich hab jetzt unter Windows,
git config --global core.autocrlf true

und unter Linux,
git config --global core.autocrlf input

für die .gitconfig gesetzt.

Scheint aber auch nicht das Problem zu sein, denn die Fehler sind immer noch da.
Wobei ich nicht zu 100% sagen kann, dass ich das richtig gemacht habe, weil es auch ne möglichkeit gibt das über eine .gitattributes Datei zu machen, aber die Beschreibungen sind irgendwie missverständlich, da soll dann alles gelöscht werden, dann renormaliziert etc. aber das hat auch nicht wirklich etwas geändert.

EDIT
Man sieht in VSC unten rechts, ob die Datei in CRLF oder LF ist. Aber auch wenn ich dort nochmal auf LF umstelle ändert es nichts.

 

[Rossie]

Erst dachte ich, dass es an der java Version liegt, aber das anpassen des JDK hat nichts gebracht.

Wie wurde das JDK angepasst? Wurde VSCode danach neu gestartet?

Entscheidend ist, wie die entsprechende Extension innerhalb von VSCode konfiguriert ist. Beschrieben ist das hier: https://marketplace.visualstudio.com/items?itemName=redhat.java#setting-the-jdk Und hier: https://code.visualstudio.com/docs/java/java-project#_configure-jdk. Man muss JAVA_HOME also nicht zwingend setzen. Ggf. wirkt sich diese Variable nicht aus.

Mit git hat das nix zu tun. Die Fehlermeldung weist auch darauf hin, dass nicht die erwartete Java-Version verwendet wird. Also Einstellungen von VSCode bzw. des Projektes überprüfen.

EDIT: Was passiert eigentlich, wenn man das Projekt im Terminal kompiliert?

$ mvn compile

 

[Z_E_R_O]

Wie wurde das JDK angepasst? Wurde VSCode danach neu gestartet?

Entscheidend ist, wie die entsprechende Extension innerhalb von VSCode konfiguriert ist. Beschrieben ist das hier: https://marketplace.visualstudio.com/items?itemName=redhat.java#setting-the-jdk Und hier: https://code.visualstudio.com/docs/java/java-project#_configure-jdk. Man muss JAVA_HOME also nicht zwingend setzen. Ggf. wirkt sich diese Variable nicht aus.

Man wird nach jeder Änderung zum Neustart aufgefordert, also ja
Müsste alles in VSC eingestellt sein, wie es sein sollte.

settings.json
{ "editor.suggestSelection": "first", "vsintellicode.modify.editor.suggestSelection": "automaticallyOverrodeDefaultValue", "files.exclude": { "**/.classpath": true, "**/.project": true, "**/.settings": true, "**/.factorypath": true }, "redhat.telemetry.enabled": false, "maven.terminal.useJavaHome": true, "java.home": "/usr/lib/jvm/jdk-16.0.2", "java.configuration.runtimes": [ { "name": "JavaSE-16", "path": "/usr/lib/jvm/jdk-16.0.2", "default": true } ], "git.suggestSmartCommit": false }

EDIT: Was passiert eigentlich, wenn man das Projekt im Terminal kompiliert?

$ mvn compile

mvn compile compiliert.
Und auch mvn spring-boot:run compiliert und startet das Programm.
Es lässt sich auch soweit bedienen bis man an eine Stelle kommt an der im Code ein Fehler angezeigt wird

 

[Rossie]

Sieht soweit gut aus. Ist im Maven Projekt definiert, welches JDK verwendet werden soll?

Poste mal die Datei. Oder zumindest den Kontext der Fehlermeldung, also einige Zeilen um Zeile 29, um zu sehen ob tatsächlich eine JDK-Klasse involviert ist.

mvn compile compiliert.

Daran sieht man, dass es nicht an git liegt.

 

[Z_E_R_O]

Sieht soweit gut aus. Ist im Maven Projekt definiert, welches JDK verwendet werden soll?

Poste mal die Datei. Oder zumindest den Kontext der Fehlermeldung, also einige Zeilen um Zeile 29, um zu sehen ob tatsächlich eine JDK-Klasse involviert ist.


Daran sieht man, dass es nicht an git liegt.

Mache ich Morgen mal vernünftig

Kann jetzt aber soviel sagen, dass er an vielen Stellen verlangt, dass ich Getter und Setter erstelle, die ich unter Windows nicht brauche, oder Variablen ohne "final" instantiieren soll, wo er unter WIndows schreit, dass das die "final" sein müssen, oder Anpassungen wo der Code dann einfach nicht mehr das macht was er soll.

 

[Rossie]

Kann jetzt aber soviel sagen, dass er an vielen Stellen verlangt, dass ich Getter und Setter erstelle, die ich unter Windows nicht brauche, oder Variablen ohne "final" instantiieren soll, wo er unter WIndows schreit, dass das die "final" sein müssen, oder Anpassungen wo der Code dann einfach nicht mehr das macht was er soll.

Das hört sich nicht nach einem JDK-Problem an. Eher so, als ob ein Tool wie Lombok nicht richtig konfiguriert ist und verrückt spielt. Werden exakt die gleichen VSCode Extensions verwendet? Wie sieht es mit den Einstellungen aus?

 

[Z_E_R_O]

Das hört sich nicht nach einem JDK-Problem an. Eher so, als ob ein Tool wie Lombok nicht richtig konfiguriert ist und verrückt spielt. Werden exakt die gleichen VSCode Extensions verwendet? Wie sieht es mit den Einstellungen aus?

Tja, das ist jetzt peinlich.
Ich habe Lombok zwar vorher schon in Betracht gezogen, aber nur mit den Dependencies rumprobiert und nicht dran gedacht, dass dafür erst noch die Extension installiert sein muss. Die habe ich unter WIndows natürlich installiert gehabt. Gibts hier den Smiley nicht mehr, der den Kopf gegen die Wand haut?

Danke an alle, deren Zeit ich verschwendet habe.
Case closed würde ich sagen.