Java Grundlagen – Block1 (Einführung in die Tool-Landschaft) – Tag 3

Ich nehme derzeit an einer Akademie zum Java Fullstack Software Engineer teil. In den kommenden Wochen möchte ich hier meine Mitschrift, so gut es geht, aufzeichnen und mitteilen. Hier ist das, was ich vom dritten Tag gelernt und behalten habe:

Maven einrichten

Maven legt eine Struktur an. Wir haben mit dem Maven-Template von gestern automatisch ein "HelloWorld" (in App.Java) und eine Testklasse (AppTest.java) angelegt bekommen:

Nach dem Anlegen eines Projektes sollte als erstes die pom.xml angeschaut werden.

Sie sagt aus, welche Technologien verwenden wir in welchem Projekt. Z.B. Zeichensätze (UTF8), oder Dependencies:

Die Klassen müssen vorhanden sein. Es reicht in der Java-Datei nicht aus sie zu importieren, sie müssen vorher auch durch die pom.xml Datei geholt werden. Maven holt dann über die .m2 Datei, wo das Repository drin steht, die entsprechenden Klassen. Diese gibt es z.B. bei https://mvnrepository.com:

Die .m2 Datei liegt hier:

https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/2.14.1

(Mit Strg - Shift -F kann man das Format automatisch anpassen)

Mit dem Speichern wird das Jar File vom Repository runter geladen und liegt dann bei uns im lokalen Repository (.m2 ist die Vorratskammer, das Java Programm ist das Rezept.):

In der Settings.xml steht der Proxy drin, von dem die Klassen importiert werden.

Hier noch mal die Maven-Übersicht:

Maven-Build Prozess

Die pom.xml Datei ist nur ein kleiner Ausschnitt der eigentlichen pom-Datei, der effektiven POM:

Der Build Prozess räumt erst mal auf (clean), holt die Ressourcen, kompilliert, erstellt das jar file,…. In der pom.xml steht der Workflow

Wir starten unser Projekt mit der rechten Maustaste und räumen erst mal auf:

Wenn wir auf Maven build klicken, werden alle Workflows durchgeführt (clean, compile,…). Als Ziel geben wir "package" ein, da wir ein jar-File als Ergebnis haben wollen:

Das Ergebnis liegt dann (nach drücken von F5) im Target Ordner:

Das Ganze geht auch mit der Konsole:

Mit der Git-Bash in das Projekt wechseln und eingeben: "mvn package"

In diesem jar file sind nur die Klassen drin, die wir selber programmiert haben, also nicht die aus dem Repository. Ich muss beim Aufrufen einen weiteren Classpath (-cp) angeben:

Git lokales Projekt mit Gitlab verknüpfen und hochladen

Wir wechseln in unsere Projekt-Ordner und geben dort in der Git-Bash "git init" ein:

Wir legen nun die .gitignore an:

Nun werden die lokalen Dateien in das lokale Staging aufgenommen.

Git add .

Commiten können wir auch schon. Aber noch nicht pushen, da für dieses Projekt noch keine Gitlab-Verbindung eingerichtet ist.

Wir hatten noch die Datei .gitlab-ci.yml vergessen, das holen wir jetzt nach. Hier ist der Inhalt:

stages:
compile
test
before_script:
# - export NO_PROXY="docker, easyng-wbench.devops.telekom.de, *.telekomcloud.com, 127.0.0.1, localhost, *.telekom.de, easyng-wbench.psst.t-online.corp, *.t-online.corp, otc-service.com, *.t-internal.com, devlab.de.tmo"
# - export HTTP_PROXY="http://proxy-vip.infrastructure.psst.t-online.corp:3128"
# - export HTTPS_PROXY=$HTTP_PROXY
echo " Doit-Befor"
java -version default: tags: run_shell
say-hello:
stage: test
script:
echo "Hello"
say-world:
stage: compile
script:
echo "World"
say-user:
stage: test
script:
echo "Hello, $GITLAB_USER_LOGIN!"

Gitlab Einstellungen:

Nun erstellen wir ein Gitlab Projekt:

Damit haben wir lokal und auf Gitlab jeweils das Projekt "proj02"

Hier mal ein Vergleich, ob die Git Konfigurationen übereinstimmen:

Git gibt auch Beispiele, wie man die beiden Repositories miteinander abgleichen kann:

Origin zeigt auf die Stelle des Remote-Projektes. Wir müssen lokal sagen, wo auf dem Server das Projekt liegt:

git remote add origin gitlab@aad-wbench.workbench.telekom.de:achim.mertens_1/proj02.git

Pushe in die Ziel URL von meinem lokalem Branch Master:

git push -u origin master

Eclipse Einstellungen

Mit der rechten Maustaste auf das Projekt klicken und Team/Share Project anklicken:

Git Perspective auswählen:

Tipp: Shortcuts werden mit Strg - Leertaste ausgeführt. Z.B. aus "Syso" wird "System.out.println()";

Leider hat es bei einigen von uns nicht geklappt Eclipse mit Gitlab zu synchronisieren. (Zum Glück geht es ja mit Git Bash). Der Fehler liegt irgendwo im SSH Schlüssel, der bei Eclipse eingetragen ist (Pfad Variable, Falscher Ordner oder so etwas). Wir haben das hier jetzt nicht weiter verfolgt.

------ Zusammenfassung -----

GIT

Lokales Projekt mit GiTRepository verknüpfen und hochladen

01. Neues Maven-Java.Projekt anlegen
Neues Maven Projekt Template: Archetype: org.apache.maven.archetypes maven-archetype-quickstart

GroupID : PackageName
ArtefactID : Projektname

02. Lokales Git-Repository anlegen
git init -> Verz.: .git

03. .gitignore anlegen (Tool-Spezifische Verzeichnisse und Dateien ausgrenzen)
touch .gitignore

.classpath
.project
.settings/
target/

04. .gitlab-ci.yml anlegen (Pipeline -> automatisierung im GitLab-Server)

    stages:
      - compile
      - test     
    before_script:
      - echo " Doit-Befor"
      - java -version
default:
tags:
 - run_shell

say-hello:
 stage: test
 script:
 - echo "Hello"

say-world:
 stage: compile
 script:
  - echo "World"

say-user:
 stage: test
 script:
 - echo "Hello, $GITLAB_USER_LOGIN!"

05. Dateien und Verzeichnisse in das lokale Staging aufnehmen
git add .

06. Git Commit ausführen um Dateien und Verzeichnisse aus dem Staging in das Reporitory zu übernehmen
git commit -m "Init Projekt"

07. Leeres GitLab Projekt "proj02" anlegen
- Login: GitLab-Server
- Projects -> Your Projects -> New Project -> Create blank project

Project name: proj02
Visibility Level: Private / Public

-> Create Projekt

08. Lokales Repository mit Remoten Repository verknüpfen

git remote add origin git@10.0.1.20:icke/proj02.git
---
Lokal
---------------------------------
Remote git@10.0.1.20:icke/proj02.git

Kontrolle:
git config --get remote.origin.url


09. Lokales Repository mit Remoten Repository syncronisieren

git push --set-upstream origin master

10. Normales arbeiten
git pull
git push

------------------

Disclaimer

Alles was ich mitschrieb und verstanden habe ist ohne Gewähr.

Besten Dank an unseren

Trainer: Hans-Joachim Blanke blanke@4point.de

Mehr dazu im nächsten Blog von mir.

Gruß, Achim Mertens