# Multi Module Maven Projekt und Git‑Submodul
## Maven Submodules

Neues Maven Submodule in Idea erstellen: 
`-> File -> New -> Module -> Maven`

### Schritt 1
![image](../uploads/56759b41a53462f6ab19e3ff904fa584/image.png){width=900 height=333}
### Scrhit 2
![image](../uploads/1de167911280f8592d5ca020b010d8a5/image.png){width=684 height=600}

![image](../uploads/a8a300b2dc6670d20928aef21e0d1320/image.png){width=684 height=600}

Output geht 👍
![image](../uploads/1eb8d9a3f42bc7da43462f62b09d51ca/image.png){width=900 height=436}

### Schritt 3
![image](../uploads/fa5f48aae8fa68291cbca0ee9acdf0cc/image.png){width=681 height=600}

![image](../uploads/f9eb2fc631e6a31e78f6944b20ba1f9b/image.png){width=852 height=286}

!!! warning "Warnung"
    Default mässig wird eine Java Klasse in Idea ohne package angabe gemacht dadruch hatte [Schritt 4](#schritt-4) probleme Oben folgendes hinzufügen:
    `package ch.bbw.skm.multimodulemaven.greeter;`

### Schritt 4
![image](../uploads/b9e7569d8ea82f56c1d900c8fad93b30/image.png){width=816 height=600}

### Schritt 5
![image](../uploads/efa40ef85ee5bef1303d67d9c61ff55b/image.png){width=900 height=587}
![image](../uploads/b2a57495e1920ddfc796cecfcf8b2b61/image.png){width=900 height=587}

### Schritt 6
![image](../uploads/ee8ebac669438c68f106deb739e931d1/image.png){width=542 height=600}

!!! note "Hinweis"
    Ausversehen `submodules` dir gelöscht zumglück in git gehabt.

![image](../uploads/b52f1b63e0229909ad2f3bf452e83ee2/image.png){width=900 height=146}

### Fragen zum Verständnis?
- Was ist ein Multi-Modul-Maven-Projekt?
Es ist ein Projekt wo aus mehreren Maven Subprojekten besteht.
- Was ist die Rolle des Parent Projektes?
Es Bundeled und Unified alle Subpackages
- Was ist die Rolle der Module?
Es entkapselt seinen relavanten Code in sich.
- Wie werden die Module in der pom.xml des Parent Projektes definiert?
Gar nicht
- Wie werden die gemeinsamen Einstellungen im Parent Projekt definiert?
Unter dem `properties` Key im `pom.xml`
- Wie wird das Parent Projekt in den Modulen referenziert?
```xml
    <parent>
        <groupId>ch.bbw.skm.multimodulemaven</groupId>
        <artifactId>multimoduleproject</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>
```
- Wie wird die Abhängigkeit von einem Modul zu einem anderen Modul definiert?
Mit einem `dependency` entry
```xml
    <dependencies>
        <dependency>
            <groupId>ch.bbw.skm.multimodulemaven</groupId>
            <artifactId>greeter-lib</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
    </dependencies>
```
- Was ist der Unterschied zwischen dem Modul `app-main` und dem Modul `greeter-lib`?
Das `app-main` kann ausgeführt werden. Während dem `greeter-lib` nur Code ist.


## Git Submodule Maven Project
`greeter-lib` in ein eigenes Git-Repo verschieben.

### Schritt 1
![image](../uploads/2adc1ef57fb17f3659ee633fb5b163af/image.png){width=900 height=467}

### Schritt 2
![image](../uploads/7cab5deb4fa895e8b69282044f779fb0/image.png){width=900 height=133}

!!! warning "Warnung"
    Darauf achten, dass die Dateien des `greeter-lib` Moduls danach **nicht mehr doppelt** im Hauptprojekt-Repository getrackt sind (z.Bsp. noch unter `submodules/greeter-lib`). Falls der Ordner vorher schon eingecheckte Dateien enthielt, müssen diese mit `git rm` aus dem Hauptrepo entfernt werden, sonst existiert der Code parallel im Submodule und im Hauptrepo.

!!! warning "Warnung"
    Git Submodule werden beim normalen `git clone` **nicht automatisch mitgeklont** — der `greeter-lib` Ordner bleibt dann leer. Nach dem Clonen zusätzlich ausführen:
    `git submodule update --init --recursive`
    (oder direkt beim Clonen: `git clone --recurse-submodules <url>`)

### Fragen zum Verständnis

- Was ist ein Git-Submodule?
Ein git submodule ist ein Git Objekt welches von git gemanaged wird um Source Code zu externalisieren.
- Wie erstellt man ein Git-Submodule?
```sh
git submodule add Git-Repo dir-name
```
- In welcher Datei werden die Git-Submodule verwaltet?
In `.gitmodules`
- Wie clont man das Hauptprojekt mit all seinen Submodulen? 
```sh
git clone --recursive Git-Repo
```
- Wie speichert man eine im Submodule 'greeter-lib` geänderte Datei im Git-Repository des Submodules?
```sh
cd greeter-lib
git add <geänderte Datei>
git commit -m "..."
git push
```
- Wie speichert man eine im Hauptprojekt geänderte Datei im Git-Repository des Hauptprojektes?
```sh
git add <geänderte Datei>
git commit -m "..."
git push
```
- Wie speichert man eine im Submodule 'app-main` geänderte Datei im Git-Repository des Hauptprojektes?
```sh
cd app-main
git add <geänderte Datei>
git commit -m "..."
git push
```
Oder
```sh
git add app-main/
git commit -m "..."
git push
```
- Wie speichert das Hauptprojekt die Referenz auf die Version des Submodules greeter-lib?

1. .gitmodules — legt fest wo (Pfad) und woher (Remote-URL) das Submodule liegt:
```
[submodule "greeter-lib"]
    path = greeter-lib
    url = git@git.foobar.vip:.../greeter-lib-subrepo.git
```
2. Gitlink im Git-Tree — für den Ordner greeter-lib legt Git im Hauptrepo einen speziellen Eintrag vom Typ 160000 an, der direkt auf einen bestimmten Commit-Hash im Submodule-Repo zeigt:
```sh
git ls-tree HEAD greeter-lib
# 160000 commit 6eddae0fc04b91fbd7f11782b32096f6b1fad018  greeter-lib
```
- Wie aktualisiert man diese Referenz im Hauptprojekt?
1. Im Submodule den gewünschten Stand auschecken/pullen (z.Bsp. neuesten Commit vom Remote holen):
```sh
cd greeter-lib
git pull origin main
cd ..
```
   (oder, für alle Submodule aufs Mal, vom Hauptprojekt aus: `git submodule update --remote greeter-lib`)
2. Den neuen Stand des Submodules im Hauptprojekt-Commit festhalten — Git erkennt, dass sich der Gitlink geändert hat, sobald der Submodule-HEAD nicht mehr mit dem gespeicherten Commit-Hash übereinstimmt (`git status` zeigt dann `modified: greeter-lib (new commits)`):
```sh
git add greeter-lib
git commit -m "update greeter-lib submodule reference"
git push
```


# IDE‑Ansatz vs. Maven/Gradle

**IDE-Ansatz (IntelliJ Artifacts):** IntelliJ hat ein eigenes, Maven-unabhängiges Artefaktmanagement. Unter `File -> Project Structure -> Artifacts` definiert man Name, Typ (z.Bsp. JAR), Output-Verzeichnis und ob das Artefakt beim Project Build automatisch mitgebaut wird; gebaut wird via `Build -> Build Artifacts`. Einbinden eines fremden Artefakts ohne Maven/Gradle: `Project Structure -> Modules -> Dependencies -> + -> JARs or Directories` und die JAR-Datei manuell auswählen. Die Konfiguration landet in den `.idea`/`.iml`-Dateien.

**Maven/Gradle-Ansatz:** Artefakt wird deklarativ in `pom.xml` (`<dependency>` mit groupId/artifactId/version) bzw. `build.gradle` (`implementation '...'`) eingetragen. Das Tool lädt es automatisch aus einem Repository (Maven Central, lokal `~/.m2`) inkl. aller transitiven Abhängigkeiten. Build via `mvn package` / `gradle build`.

| | IDE-Ansatz | Maven/Gradle |
|---|---|---|
| ➕ | Schnell per GUI, kein Setup, gut für kleine Experimente | Portabel (CLI, CI/CD, jede IDE), Versionierung, transitive Dependencies, Repositories |
| ➖ | Proprietär (an IntelliJ gebunden), nicht CI/CD-fähig, JARs manuell beschaffen/aktualisieren, keine transitiven Dependencies | Mehr Initialaufwand, XML/DSL lernen |

**Fazit:** IDE-Artefakte sind für lokale Ausnahmen okay; für alles Teamfähige und Automatisierte (DevOps!) sind Maven/Gradle der Standard, weil der Build reproduzierbar und toolunabhängig ist.

# Refresher: Was ist ein Maven‑Artefakt?

## Bedeutung von Begriffen
- **GroupId:** uniquely identifies a project group across all other groups. Each groupId should follow Java's package name rules. This means it starts with a reversed domain name you control.
_Examples:_
```
org.apache.maven
org.apache.commons
com.google.guava
```
- **ArtifactId:**  is the name of the artifact. The identifiers should only consist of lowercase letters, digits, and hyphens.
_Examples:_
```
commons-math
maven-clean-plugin
```
- **Version:**`  follow the rules of [Semantic Versioning 1.0.0](https://semver.org/spec/v1.0.0.html). It should start with the major version, followed by the minor version and the patch version. All three are numeric, separated by a dot. You can add labels for pre-releases or build metadata after the patch version. Avoid using dates in those labels, because they are usually associated with unstable versions.
_Examples:_
```
1.0.0
2.3.2
3.5.42
// Pre-releases
1.0.0-beta
1.0.0-M1
1.0.0-rc2

// Build metadata
1.2.3+dfc0c87
2.3.4+15433
```
- **Packaging:** give us a really complete what: that is the project's packaging (`JAR|WAR`)
- **Classifier:** The classifier distinguishes artifacts that were built from the same POM but differ in content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number.
  As a motivation for this element, consider for example a project that offers an artifact targeting Java 11 but at the same time also an artifact that still supports Java 1.8. The first artifact could be equipped with the classifier `jdk11` and the second one with `jdk8` such that clients can choose which one to use.

## Aufbau eines Maven Artifakt
> Erarbeiten Sie den Aufbau eines Maven‑Artefakts.Aufbau festhalten und erklären.

Ein Maven-Artefakt ist eine Datei (meistens ein JAR), die in einem Maven-Repository abgelegt und über ihre **Koordinaten** eindeutig identifiziert wird:

```
groupId:artifactId:packaging:classifier:version
```
_Beispiel:_ `org.apache.commons:commons-lang3:jar:3.12.0`

Nur `groupId:artifactId:version` (**GAV**) sind Pflicht — `packaging` (Default: `jar`) und `classifier` sind optional.

**Dateiname** nach Konvention:
```
<artifactId>-<version>[-<classifier>].<packaging>
z.Bsp. greeter-lib-1.0-SNAPSHOT.jar
       commons-lang3-3.12.0-sources.jar
```

**Ablage im Repository** — die Koordinaten bestimmen den Pfad:
```
<repo>/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar
       └── groupId (Punkte = Ordner) ──┘└ artifactId ┘└ version ┘
```

**Inhalt eines JAR-Artefakts:**
- kompilierte `.class`-Dateien (in der Package-Struktur)
- `META-INF/MANIFEST.MF` (Metadaten, ggf. Main-Class)
- `META-INF/maven/<groupId>/<artifactId>/pom.xml` + `pom.properties` — das Artefakt trägt seine eigene Baubeschreibung mit

Daneben liegen im Repository zum selben Artefakt typischerweise die `.pom`-Datei (für transitive Dependencies), Checksummen (`.sha1`) und optional `-sources.jar` / `-javadoc.jar` als Classifier-Varianten.

# Lokales Maven‑Repository
- Path (Linux/*NIX): `~/.m2`

## Custom LocalRepo Config File

Add the following snippet to `~/.m2/settings.xml`:
```xml
<settings>
    <localRepository>/path/to/maven_repository</localRepository>
    ...
```

## Custom LocalRepo CLI
```sh
mvn -Dmaven.repo.local=/path/to/maven_repository clean install
```

!!! note "Hinweis"
    Important argument is `-Dmaven.repo.local=/path/to/maven_repository`

# Artefakte zur Verfügung stellen
> Recherchiere Möglichkeiten, ein Maven‑Artefakt zu veröffentlichen (Maven Central, Nexus/Artifactory, GitHub Packages, File‑Sharing).
> Beschreiben kurz zu den jeweiligen Möglichkeiten, wie man vorgeht, um ein Artefakt zu veröffentlichen.
> Halten Sie Vor‑ und Nachteile der jeweiligen Möglichkeit fest.

## GitLab Packages
**Vorgehen:** In `pom.xml` `<distributionManagement>` mit der GitLab-Registry-URL (`.../api/v4/projects/<id>/packages/maven`) eintragen, Auth-Token in `settings.xml`, dann `mvn deploy`.
- ➕ Direkt beim Repo (CI/CD-Integration), private Packages gratis
- ➖ Nur für Nutzer mit GitLab-Zugang, Token-Handling nötig

## Maven Central
**Vorgehen:** Account beim Central Portal, groupId (Domain) verifizieren, Artefakt muss Sources + Javadoc + GPG-Signatur enthalten, dann via `maven-publish`/`central-publishing-maven-plugin` deployen.
- ➕ Weltweit standardmässig verfügbar, kein Repo-Eintrag beim Konsumenten nötig
- ➖ Aufwändiges Setup, strenge Anforderungen, nur öffentlich, kein Löschen möglich

## Nexus/Artifactory
**Vorgehen:** Eigenen Repository-Server betreiben, Repo anlegen, URL in `<distributionManagement>` + Credentials in `settings.xml`, `mvn deploy`.
- ➕ Volle Kontrolle, privat, Proxy/Cache für Central
- ➖ Server selbst betreiben und warten (Kosten, Aufwand)

## File-Sharing
**Vorgehen:** `mvn package`, JAR (+ pom) manuell verschicken/ablegen (Mail, Ordner, Cloud); Empfänger installiert mit `mvn install:install-file -Dfile=... -DgroupId=... -DartifactId=... -Dversion=...`.
- ➕ Null Infrastruktur, sofort
- ➖ Keine Versionierung/transitive Dependencies, manuell, fehleranfällig — nicht teamtauglich

---

# Sources
- https://bbw-it.github.io/324_main_rupe/14_MavenArtefacts/14.1-JavaProjektUndArtefakte/
- https://bbw-it.github.io/324_main_rupe/50_KnowledgeBase/14_MavenArtefacts/MultiModuleMavenProject/
- https://bbw-it.github.io/324_main_rupe/50_KnowledgeBase/14_MavenArtefacts/GitSubmoduleMavenProject/
- https://www.jetbrains.com/help/idea/artifacts.html
- https://maven.apache.org/guides/mini/guide-naming-conventions.html
- https://maven.apache.org/pom.html#packaging
- https://www.baeldung.com/maven-local-repository
- https://maven.apache.org/settings.html