# Maven- und andere Abhängigkeiten



## von Spotz (27. Nov 2021)

Hallo

wenn ich ein import statement habe wie dieses

1


```
import org.apache.kafka.clients.consumer.ConsumerRecord;
```

1.1 Woher weiß ich, welcher teil davon groupId und welcher ArtifactId ist?

1.2 Von welchem Repository werden die dependencies geladen?

1.3 Welches Format haben die dependencies, wenn sie über die POM.xml geladen werden? Maven-Pakete?

1.4 Gibt es einen Standard, wo die geladenen dependencies lokal gespeichert werden? Gibt es da eine Umgebungsvariable von Java? Ist das IDE-spezifisch?

2 Was ist

https://mvnrepository.com/artifact/org.apache.kafka
bzw

https://search.maven.org/classic/#search|ga|1|

3

Wenn ich Kafka beispielsweise als Paket von https://kafka.apache.org/downloads heruntergeladen habe, nach "/usr/local/kafka" extrahiert und zu *$PATH* hinzugefügt habe, kann die IDE dann diese binaries benutzen?

4

_Betrifft Microservices bzw. Container_
Was ist mit den Dependencies, die über Container geladen werden? Wahrscheinlich können diese nicht benutzt werden, oder?

Danke
Maximilian (Ich hätte mich besser rubyist nennen sollen. Dann wäre klar, warum (u.a.) Java Konzepte mir zum Teil etwas fremd sind. Unter ruby benutzt man für Abhängigkeiten Gemfiles, das Kommandozeilentool rubygems und dieses wahrscheinlich in Kombination mit dem RVM, dem ruby version manager. Repository ist, falls nicht angegeben, stets github. )


----------



## kneitzel (27. Nov 2021)

von Spotz hat gesagt.:


> Woher weiß ich, welcher teil davon groupId und welcher ArtifactId ist?


Gar nicht. Das sind zwei komplett voneinander unabhängige Dinge. Das was Du da gezeicht hast ist der Import eines namespaces. Der hat absolut nichts mit groupId oder artifactId zu tun. Es kommen nur teilweise ähnliche Dinge vor, da z.B. gerne die Domain verwendet wird. Das ändert aber absolut nichts daran, dass diese Dinge unabhängig voneinander sind.



von Spotz hat gesagt.:


> Von welchem Repository werden die dependencies geladen?


Wenn Du in Maven kein anderes Repository hinterlegt hast, dann wird das Maven Central Repository verwendet. Aber es können andere Repositories hinterlegt werden und dann wird auch auf diesen nach einer Abhängigkeit gesucht.


von Spotz hat gesagt.:


> Welches Format haben die dependencies, wenn sie über die POM.xml geladen werden? Maven-Pakete?


Du kannst Dir auf https://mvnrepository.com/ ja ansehen, was hinterlegt ist. Dies ist in erster Linie das jar File und eine pom.xml. Das jar File enthält halt die eigentliche Abhängigkeit, die geladen werden soll und die pom enthält ggf. weitere transitive Abhängigkeiten. Zusätzlich können aber noch mehr Dinge hinterlegt werden wie Plattform spezifische jar Dateien, JavaDoc, Sourcen, ...


von Spotz hat gesagt.:


> Gibt es einen Standard, wo die geladenen dependencies lokal gespeichert werden? Gibt es da eine Umgebungsvariable von Java? Ist das IDE-spezifisch?


Das ist Maven spezifisch. Im Home-Verzeichnis findet sich das Verzeichnis .m2 und da landen alle Dinge von Maven. Also z.B. das lokale Repository findet sich dort.


von Spotz hat gesagt.:


> Was ist ...


Das sind einfach nur Seiten, die das Maven Central Repository für Dich durchsuchbar machen und die die hinterlegten Informationen anschaulich darstellen. Oder auf was willst Du hinaus?


von Spotz hat gesagt.:


> Wenn ich Kafka beispielsweise als Paket von https://kafka.apache.org/downloads heruntergeladen habe, nach "/usr/local/kafka" extrahiert und zu *$PATH* hinzugefügt habe, kann die IDE dann diese binaries benutzen?


Also der PATH ist erst einmal Java und der IDE relativ egal. Für das Java Projekt spielt es keine Rolle, denn das ist nur der Such-Pfad für Binaries. In dem Java Projekt musst du angeben, welche JAR Dateien eingebunden werden. Bei maven geht dies über Dependencies und die IDEs haben da bei Ihren eigenen Projekten eigene Methoden. Prinzipiell kann es auch ein jar File sein, das irgendwo liegt.
Dies sollte aber NICHT gemacht werden. Wenn Du im Projekt auf ein Verzeichnis / eine Datei außerhalb des Projektes verweist, dann muss diese ja so bei allen Entwicklern vorhanden sein. Also jedes Build System muss entsprechend aufgebaut sein. Das sind alles unnötige Anforderungen und man sollte relativ unabhängig von solchen Dingen sein. Gerade mit Maven reicht es aus, einen Rechner (egal ob Windows oder Unix Artig) zu nehmen und Java (in der richtigen / kompatiblen Version) zu installieren um ein Maven Projekt zu bauen - so der Maven Wrapper integriert wurde. Das macht es Entwicklern sehr einfach.


von Spotz hat gesagt.:


> Was ist mit den Dependencies, die über Container geladen werden? Wahrscheinlich können diese nicht benutzt werden, oder?


Kannst Du das einmal ausführen? Was genau meinst du? Wenn Du eine Abhängigkeit zu einem anderen Service hast, dann wird da ja eine Schnittstelle definiert worden sein. Und diese kann dann ganz normal mit integriert werden, so diese als Dependencie bereit steht.


von Spotz hat gesagt.:


> Ich hätte mich besser rubyist nennen sollen. Dann wäre klar, warum (u.a.) Java Konzepte mir zum Teil etwas fremd sind.


Das ist hier aber doch auch nicht groß anders. Man hat Maven oder Gradle, Repository ist in der Regel das Maven Central Repository. Du hast die Informationen zu den Abhängigkeiten aber halt innerhalb des pom.xml Files.


----------



## von Spotz (21. Dez 2021)

kneizel hat gesagt.:
			
		

> Gar nicht. Das sind zwei komplett voneinander unabhängige Dinge. Das was Du da gezeicht hast ist der Import eines namespaces. Der hat absolut nichts mit groupId oder artifactId zu tun. Es kommen nur teilweise ähnliche Dinge vor, da z.B. gerne die Domain verwendet wird. Das ändert aber absolut nichts daran, dass diese Dinge unabhängig voneinander sind.
> 
> 
> Wenn Du in Maven kein anderes Repository hinterlegt hast, dann wird das Maven Central Repository verwendet. Aber es können andere Repositories hinterlegt werden und dann wird auch auf diesen nach einer Abhängigkeit gesucht.
> ...


Hallo Kneitzel,

erst einmal Entschuldigung, daß ich erst jetzt antworte. 

Ich habe mich vielleicht etwas mißverständlich ausgedrückt. Ich meinte gerade das, worüber Du bei meiner Frage "gestolpert" bist: Genau, es sind zwei paar Schuhe. Worauf ich eigentlich hinaus wollte, war, ob es möglich ist, aus dem import-string groupId und artifactId zu extrahieren, sodaß ich die dazugehörige Abhängigkeit richtig auflösen kann.



			
				kneizel hat gesagt.:
			
		

> vonSpotz hat gesagt.:
> 
> 
> 
> ...


Ich weiß nicht, ob man über die POM.xml binaries wie z.B. Kafka oder MySQL laden kann. Ich bin davon ausgegangen, daß das nicht geht, sondern daß diese auf andere Weise auf dem System installiert sein müssen, damit ein Java-Projekt, welches auf diese binaries zugreifen muss, auch gestartet werden kann. Und schließlich kann man binäre Abhängigkeiten auch über Docker-Images hinzufügen (bei Kubernetes geht das sicher auch) z.B. https://hub.docker.com/r/bitnami/kafka oder https://hub.docker.com/_/mysql 
Was ich nun meinte war, ob diese dependencies benutzt werden können, wenn ich mein Java-Projekt aus der IDE heraus starte bzw. daß dies wohl eher nicht möglich ist, solange ich die .jar Datei von dem Projekt nicht über die Kommandozeile containerisiert habe und sich diese im gleichen Ordner befinden, wie die o.g. Images und das Dockerfile.

Alles Gute!


----------



## LimDul (21. Dez 2021)

von Spotz hat gesagt.:


> Hallo Kneitzel,
> 
> erst einmal Entschuldigung, daß ich erst jetzt antworte.
> 
> Ich habe mich vielleicht etwas mißverständlich ausgedrückt. Ich meinte gerade das, worüber Du bei meiner Frage "gestolpert" bist: Genau, es sind zwei paar Schuhe. Worauf ich eigentlich hinaus wollte, war, ob es möglich ist, aus dem import-string groupId und artifactId zu extrahieren, sodaß ich die dazugehörige Abhängigkeit richtig auflösen kann.


Nein, das geht nicht. Es ist schlicht unmöglich, da viele Projekte ihre Artefakt-IDs nicht an den Packagenamen ausrichten. 




> Ich weiß nicht, ob man über die POM.xml binaries wie z.B. Kafka oder MySQL laden kann. Ich bin davon ausgegangen, daß das nicht geht, sondern daß diese auf andere Weise auf dem System installiert sein müssen, damit ein Java-Projekt, welches auf diese binaries zugreifen muss, auch gestartet werden kann. Und schließlich kann man binäre Abhängigkeiten auch über Docker-Images hinzufügen (bei Kubernetes geht das sicher auch) z.B. https://hub.docker.com/r/bitnami/kafka oder https://hub.docker.com/_/mysql
> Was ich nun meinte war, ob diese dependencies benutzt werden können, wenn ich mein Java-Projekt aus der IDE heraus starte bzw. daß dies wohl eher nicht möglich ist, solange ich die .jar Datei von dem Projekt nicht über die Kommandozeile containerisiert habe und sich diese im gleichen Ordner befinden, wie die o.g. Images und das Dockerfile.
> 
> Alles Gute!


Definiere binaries. POM.xml geben Abhängigkeiten an und darüber kann z.b. Mavn die benötigten Jar-Dateien (Was du vermutlich mit Binaries meinst) laden, so dass die, wenn sie dem Classpath hinzugefügt werden, das Programm startbar machen


----------



## kneitzel (21. Dez 2021)

Ein einfaches "extrahieren" ist nicht möglich. Aus den Namespaces lässt sich nicht die groupid / artefactid ableiten. Der Anwendungsfall ist auch etwas speziell: Woher kommt der Namespace, wenn man die Abhängigkeit nicht kennt?

In so einem Fall (Ich kenne das hier z.B. aus dem Forum. Es schreibt jemand über etwas ohne es genau zu spezifizieren) suche ich per Google, was für Abhängigkeiten es sein könnten um mir dann diese anzusehen. Wichtig ist dabei: Es muss nicht eindeutig sein! Ein Namespace kann durch mehrere Projekte verwendet worden sein! Es gibt zwar gewisse Vorgaben a.la. reverse Domain, aber danach richtet sich nicht jeder. Aber selbst wenn, es kann ja mehrere Versionen geben.

Und bezüglich der Abhängigkeiten ist immer die Frage, was Du genau willst! Beispiel Datenbanken: Ja, in der Regel hat man separat installierte Datenbanken (mysql hast Du ja als Beispiel benannt). Diese müssen dann natürlich installiert sein. Aber natürlich gibt es auch embedded Datenbanken. Dann ist die Datenbank mit integriert. Das gibt es in vielen Bereichen. Tomcat wird in der Regel separat installiert, aber es gibt ihn auch embedded. Hier ist also wirklich die Frage, was Du genau willst und brauchst.

Aber dein Kernproblem ist ggf. einfach nur:


von Spotz hat gesagt.:


> wenn ich mein Java-Projekt aus der IDE heraus starte


Da ist dann die Frage, was Du wie starten willst! Als Entwickler bist Du ja nicht an dem Produkt selbst interessiert sondern mehr an den Unit Tests. Und da ist es üblich, dass externe Abhängigkeiten ersetzt werden. Dies nennt man dann "mocking". Generell spricht aber nichts dagegen, darauf zu verzichten: Dann hat man halt die externen Komponenten ebenfalls (also z.B. ein lokal installiertes mysql mit der entsprechenden (Test)Datenbank.
Dies mag einem das "mocken" ersparen, aber man erkauft es sich sehr teuer: Der Entwickler-Arbeitsplatz wird dadurch unnötig komplexer, d.h.
- Aufbau wird komplexer
- Fehleranfälliger
- ...
Ich erinnere mich an projekte - da war ein Neuaufbau eines Computers ein Job von 2 Tagen. Ein Tag reines Installieren und konfigurieren und dann ein zweiter Tag das Anstarten aller möglicher Unit Tests mit Fehlerbehebungen und so... Bei anderen Projekten sah es anders aus: Eine Installtion des Betriebssystems war in 2 Stunden erledigt, dann noch das Java/git drauf (IDE auch noch, klar, aber das ist keine Pflicht!) und schon konnte man nach einem pull der Sourcen ein mvnw starten und alles lief incl. compile, test, build, ....

Integrationstest sind ein anderes Kaliber. Da hat man dann eine Integrationsumgebung, d.h. die externen Systeme sind auch vorhanden. Das mag man auch automatisieren aber ist unabhängig vom Entwickler und dessen Arbeitsplatz zu sehen. (Man mag da ggf. auch debuggen wollen. Dazu gibt es dann remote debugging Möglichkeiten).

Hat dies evtl. etwas geholfen?

Viele Grüße,

Konrad


----------



## von Spotz (22. Dez 2021)

Hallo Kneitzel,

Danke für Deine Antwort !



			
				kneitzel hat gesagt.:
			
		

> Und bezüglich der Abhängigkeiten ist immer die Frage, was Du genau willst! Beispiel Datenbanken: Ja, in der Regel hat man separat installierte Datenbanken (mysql hast Du ja als Beispiel benannt). Diese müssen dann natürlich installiert sein. Aber natürlich gibt es auch embedded Datenbanken. Dann ist die Datenbank mit integriert. Das gibt es in vielen Bereichen. Tomcat wird in der Regel separat installiert, aber es gibt ihn auch embedded. Hier ist also wirklich die Frage, was Du genau willst und brauchst.
> 
> Aber dein Kernproblem ist ggf. einfach nur:
> 
> ...


Ich beziehe mich auf kontainerisierte Microservice Anwendungen, beziehungsweise deren einzelne Projekte (domain services) und darauf, daß ich die Abhängigkeiten nicht lokal installiert habe, sondern diese in dem Container laufen, in dem der domain-service als .jar laufen soll. Dann kann ich entweder das zugehörige Javaprojekt nicht testen, ohne bei jeder Codeveränderung manuell den Container zu starten oder einen Orchestrator oder ein Skript, das den Container und andere startet - oder es gibt eine Möglichkeit, den Container mit dem .jar file, welches das Projekt erzeugt, automatisch aus der IDE heraus zu starten. Ansonsten fehlen ja die Abhängigkeiten. Gibt es so eine Möglichkeit? Für die Antwort auf die Frage relevant ist auch noch eine untergeordnete Frage, und zwar, ob ein container-orchestrator-service ein normaler service ist, so wie ein service-discovery-service, der Teil von meinem Microservice ist, oder auch etwas, das prinzipiell nicht über die Java-IDE (und dann meinetwegen über unit tests) gestartet werden kann und vielleicht sogar extern zu meinem Microservice ist.
,


----------



## kneitzel (22. Dez 2021)

von Spotz hat gesagt.:


> Dann kann ich entweder das zugehörige Javaprojekt nicht testen


Sorry, wenn ich das immer noch nicht wirklich verstanden habe. Um was für Tests geht es Dir denn genau?
- Unit Tests sollten unabhängig sein - da würden Abhängigkeiten gemockt und dann laufen diese in der IDE
- Integration Tests - da würde dann tatsächlich deployed um dann das Zusammenspiel auszutesten.

Und auch das Verständnis: Nur weil die jar Datei in irgend einem Container landet am Ende: Es ist und bleibt eine jar Datei und die lässt sich natürlich auch ausßerhalb eines Containers starten. Es gibt ggf. ein paar Abhängigkeiten und diese muss man bereit stellen, aber das dürfte einfach heraus zu finden sein, da ja ein Container gebaut wird: Abhängigkeiten fließen da ja zwangsläufig ein. Somit sollte es möglich sein, das auch direkt in der IDE anzustarten. Das ist aber eine theoretische Sache - ob man dies in der Praxis machen will oder nicht hängt natürlich von den Aufwänden und den Anforderungen ab. Gerade wenn es Abhängigkeiten zu anderen Diensten gibt, dann wird das ggf. schnell recht komplex - und dann ist es tatsächlich einfacher, direkt Richtung Integrationstest zu gehen, sprich: Man hat zur Not Docker Container und die werden dann gestartet.

Aber da ich das so eigentlich schon geschrieben habe, ist es wohl wirklich so, dass ich Deine Problematik vermutlich noch nicht richtig verstanden habe und ich nicht sehe, worauf Du genau hinaus willst.


----------



## mrBrown (24. Dez 2021)

ich werfe mal Testcontainers in den Raum, damit kann man aus Java-Code alle für Tests benötigte Dienste starten, zB sogar völlig automatisiert und transparent, zB bei JDBC-Datenbanken.


----------



## von Spotz (29. Dez 2021)

Hallo Kneitzel,

ok ich merke, da ist offensichtlich ein Problem in unserer Kommunikation. Ich habe "Testen" nicht formal gebraucht, etwa im Sinn von Unit Tests. Sondern im Sinn von Trial & Error: 



			
				vonSpotz hat gesagt.:
			
		

> Neuen Code hinzufügen oder Code verändern => Laufen lassen => Funktioniert es? => Ja? => Fertig, Nein? => Anpassen => Neuen Code hinzufügen oder Code verändern => Laufen la...





			
				Kneitzel hat gesagt.:
			
		

> Und auch das Verständnis: Nur weil die jar Datei in irgend einem Container landet am Ende: Es ist und bleibt eine jar Datei und die lässt sich natürlich auch ausßerhalb eines Containers starten. Es gibt ggf. ein paar Abhängigkeiten und diese muss man bereit stellen


Das ist gerade das Problem, das ich ansprechen möchte. _Was,_ wenn binäre Abhängigkeiten, die die Applikation zum Laufen benötigt, eben über einen Container bereitgestellt werden? (siehe die Links zu den Docker-Images die ich gepostet habe)

Dann kann man eine .jar eben erst starten, wenn diese in dem ihr spezifischen Container containerisiert wurde. Das scheint mich aus der IDE herauszuzwingen und das eben gesagte eben händisch über die Konsole zu tun. Außer, das hier (https://www.java-forum.org/thema/ko...chestrator-microservices.194831/#post-1290093) würde zutreffen und ich könnte aus der IDE mit dem Orchestrator Service kommunizieren (insofern es sich um einen service handelt und dieser nicht extern zu dem Microservice ist)

Viele Grüße!
von Spotz


----------



## kneitzel (29. Dez 2021)

von Spotz hat gesagt.:


> _Was,_ wenn binäre Abhängigkeiten, die die Applikation zum Laufen benötigt, eben über einen Container bereitgestellt werden?


Dann kannst Du entweder einen solchen Container nutzen (Docker for Desktop oder sonst irgendwie) oder das, was eben in dem Docker Container läuft, lässt Du direkt auf Deinem Rechner laufen. So ein Container ist ja nichts magisches. Da läuft auch ganz normal eine Anwendung drin. Der Container ist nur eine virtuelle Ebene, die eben das Deployment vereinfachen und Störungen verhindern soll.



von Spotz hat gesagt.:


> Dann kann man eine .jar eben erst starten, wenn diese in dem ihr spezifischen Container containerisiert wurde.


Wieso denn das? Natürlich sollte eine jar Datei sich auch ausserhalb des Containers starten lassen. Was für Abhängigkeiten notwendig sind, ist in der Regel auch sehr gut (durch die Beschreibung des Containers) dokumentiert. Daher verstehe ich diese Aussage nicht. Was hast Du für eine JAR Datei, die eben explizit den Container benötigt?
Wenn Du eine Abhängigkeit zu Kubernetes oder so hast, dann ist das eine dedizierte Abhängigkeit, aber die würde dann auch nicht dafür sorgen, dass es nur in einem Container läuft. Alles, was dann notwendig wäre, wäre halt der Zugriff auf einen Kubernetes Kluster ... (Nur um ein Beispiel zu nennen).

Und damit hast Du dann genau das, was ich auch schon grob umschrieben hatte: Ich war einmal in einem Projekt, wo auf das Mocken der Schnittstellen verzichtet wurde. Die Schnittstellen liefen dann entweder auch auf dem Entwicklungsrechner (Datenbanken und sowas) oder es gab dedizierte Testsysteme, auf die Zugegriffen wurde. (Ich war damals im Bereich Automatisierung von Administrativen Dingen unterwegs - und da hatten wir dann halt eine Testumgebung, die so aufgebaut war, wie die produktive Umgebung. Incl. Domain Controller, DFS, NAS Systemen ...)

Das geht also alles, aber es gibt einen enormen Overhead denn so eine Umgebung muss ja korrekt aufgebaut sein. (Unsere Entwicklung umfasste dann auch Scripte, die die ganze Testumgebung aufgesetzt hat.) Sowa sist aber ggf. bei euch sogar richtig einfach, so die Abhängigkeiten auch in Containern sind ...


----------



## von Spotz (29. Dez 2021)

Ja, danke MrBrown. Genau dieses "Testcontainers" (was ist das eigentlich? Ein "Plugin" für die IDE? Wieder eine Anfängerfrage in der für mich neuen Javawelt) ist in etwa die Lösung zu dem Problem das ich habe. Aber es funktioniert nur für UnitTests, oder? Woran ich gedacht hatte, war ja prinzipiell die Möglichkeit, von Maven erzeugte .jar Dateien aus der IDE heraus containerisiert zu starten und laufen zu lassen. Also in echt und nicht nur irgendwie "herumgetrickst" mit Netz und doppeltem Boden. Eben vielleicht über die Cluster Orchestration. (nochmal https://www.java-forum.org/thema/ko...chestrator-microservices.194831/#post-1281770)

Viele Grüße!
von Spotz


----------



## von Spotz (29. Dez 2021)

Hallo Kneitzel,
nun weiß ich leider wirklich nicht mehr weiter. Also ich rede ja davon, auf mocking zu verzichten, so wie das wahrscheinlich Testcontainers tut (also zu mocken, nicht aber nicht zu mocken), aber auch davon, daß die binären Abhängigkeiten der .jar nicht auf dem System installiert sind. 
Sondern, daß die .jar beim Starten aus der IDE automagisch containerisiert wird. Ansonsten beschwert sich die JavaVM beim Ausführen doch über fehlende Abhängigkeiten, oder nicht? Außerdem _möchte_ ich vielleicht einen oder mehrere Services des Microservices den ich schreibe containerisiert parallel laufen lassen ohne daß dies in einen UnitTest eingebunden ist.


----------



## temi (29. Dez 2021)

von Spotz hat gesagt.:


> Ich weiß nicht, ob man über die POM.xml binaries wie z.B. Kafka oder MySQL laden kann. Ich bin davon ausgegangen, daß das nicht geht, sondern daß diese auf andere Weise auf dem System installiert sein müssen, damit ein Java-Projekt, welches auf diese binaries zugreifen muss, auch gestartet werden kann.


Ich bin mir nicht sicher, ob ich verstanden habe, was du uns sagen möchtest. Nehmen wir als Beispiel das genannte MySql.

Du schreibst eine Anwendung, die MySql verwenden möchte. Für den Zugriff auf eine MySql-DB brauchst du nun entsprechende "Treiber", die du in deinem Programm verwendest. Die .jar mit diesen Treibern muss natürlich in deinem Projekt vorhanden sein, damit du sie in deinem Programm importieren und verwenden kannst (eingebunden z. B. mit Maven oder Gradle). Die eigentliche MySql-DB, auf die du aus deinem Programm zugreifen willst, kann dagegen völlig unabhängig irgendwo laufen. Als laufende Instanz auf deinem PC, irgendwo auf einem Server oder auch in einer VM oder in einem Container. In allen diesen Fällen gibt es Zugriffsdaten (IP-Adresse usw.) mittels derer du dich mit der laufenden MySql Instanz verbindest.

Du musst KEINE MySql-DB in deinem Projekt haben, nur die Abhängigkeiten zu den "Treibern". Allerdings wirst du natürlich keine Verbindung zu einer DB aufbauen können, wenn keine DB irgendwo läuft.

Aber evtl. habe ich alles falsch verstanden...

Möchtest du evtl. z. B. die SQL-Instanz (z. B. in einem Container) über Maven starten (sobald du dein Programm startest)?


----------



## von Spotz (29. Dez 2021)

temi hat gesagt.:
			
		

> Du schreibst eine Anwendung, die MySql verwenden möchte. Für den Zugriff auf eine MySql-DB brauchst du nun entsprechende "Treiber", die du in deinem Programm verwendetst. Die .jar mit diesen Treibern muss natürlich in deinem Projekt vorhanden sein, damit du sie in deinem Programm importieren und verwenden kannst (eingebunden z. B. mit Maven oder Gradle).


Korrekt!



			
				temi hat gesagt.:
			
		

> Die eigentliche MySql-DB, auf die du aus deinem Programm zugreifen willst, kann dagegen völlig unabhängig irgendwo laufen. Als laufende Instanz auf deinem PC, irgendwo auf einem Server oder auch in einer VM oder in einem Container. In allen diesen Fällen gibt es Zugriffsdaten (IP-Adresse usw.) mittels derer du dich mit der laufenden MySql Instanz verbindest.


Korrekt!



			
				temi hat gesagt.:
			
		

> Du musst KEINE MySql-DB in deinem Projekt haben, nur die Abhängigkeiten zu den "Treibern". Allerdings wirst du natürlich keine Verbindung zu einer DB aufbauen können, wenn keine DB irgendwo läuft.


Korrekt!


			
				temi hat gesagt.:
			
		

> Möchtest du evtl. z. B. die SQL-Instanz (in einem Container) über Maven starten (sobald du dein Programm startest)?


Combo korrekt!

Beziehungsweise um es ganz präzise zu sagen: in dem Container in dem eben ein MySql Image läuft, auf das die Treiber der containerisierten .jar dann als Abhängigkeit zugreifen.

Also:


			
				temi hat gesagt.:
			
		

> Aber evtl. habe ich alles falsch verstanden...


Nein 

Vielen Dank für das Klarifizieren meines Anliegens


----------



## temi (29. Dez 2021)

von Spotz hat gesagt.:


> Beziehungsweise um es ganz präzise zu sagen: in dem Container in dem eben ein MySql Image läuft, *auf das die Treiber der containerisierten .jar dann als Abhängigkeit zugreifen.*


Diesen Teil verstehe ich nicht. Vielleicht erläuterst du das noch einmal möglichst verständlich.

Die DB läuft in einem Container. Der Container hat eine IP-Adresse, die Zugangsdaten zur DB kennst du wohl.

Du startest aus der IDE deine Anwendung und verbindest dich mit der DB im Container. Fertig.

Die Treiber gehören als jar zu deinem Programm, die sind ja nicht in einem Container.


----------



## von Spotz (29. Dez 2021)

temi hat gesagt.:


> Diesen Teil verstehe ich nicht. Vielleicht erläuterst du das noch einmal möglichst verständlich.
> 
> Die DB läuft in einem Container. Der Container hat eine IP-Adresse, die Zugangsdaten zur DB kennst du wohl.
> 
> ...


Ok, dann muss ich aber den Container manuell über die Konsole und völlig unabhängig von der .jar im Vorfeld starten oder nicht? Ich möchte aber gerne, daß die IDE die .jar Datei "automagisch" in dem Container startet, der die entsprechende Konfiguration (Dockerfile) und docker-Images enthält. Ansonsten kann ich die .jar ja auch nicht parallelisiert oder einfach containerisiert i.V.m. anderen Teilprojekten des Microservice testen. Außerdem klingt diese Trennung von .jar und Container recht kompliziert: Erst einen oder mehrere verschiedene Container "leer" starten, dann die Treiber in den verschiedenen Services/Projekten entsprechend konfigurieren - nur für den Zugriff auf die Datenbank. Das erfordert dann nacher wieder, daß ich alles wieder ummodel und so konfiguriere, daß die .jar in dem Container laufen kann statt extern dazu. Außerdem: Was ist mit anderen binaries wie Kafka? Bekommt die .jar auf ein kafka-image auch Zugriff durch Angabe vom Container Port? Die IP Adresse wäre in der von Dir vorgeschlagenen Lösung _localhost_ oder?

Viele Grüße!
von Spotz


----------



## temi (29. Dez 2021)

von Spotz hat gesagt.:


> Ok, dann muss ich aber den Container manuell über die Konsole und völlig unabhängig von der .jar im Vorfeld starten oder nicht? Ich möchte aber gerne, daß die IDE die .jar Datei "automagisch" in dem Container startet, der die entsprechende Konfiguration (Dockerfile) und docker-Images enthält. Ansonsten kann ich die .jar ja auch nicht parallelisiert oder einfach containerisiert i.V.m. anderen Teilprojekten des Microservice testen. Außerdem klingt diese Trennung von .jar und Container recht kompliziert: Erst einen oder mehrere verschiedene Container "leer" starten, dann die Treiber in den verschiedenen Services/Projekten entsprechend konfigurieren - nur für den Zugriff auf die Datenbank. Das erfordert dann nacher wieder, daß ich alles wieder ummodel und so konfiguriere, daß die .jar in dem Container laufen kann statt extern dazu. Außerdem: Was ist mit anderen binaries wie Kafka? Bekommt die .jar auf ein kafka-image auch Zugriff durch Angabe vom Container Port? Die IP Adresse wäre in der von Dir vorgeschlagenen Lösung _localhost_ oder?
> 
> Viele Grüße!
> von Spotz


Tut mir leid. Es ist mir vollkommen schleiferhaft, wovon du da schreibst. Was ist denn *die* .jar? Und wieso Container leer starten?

Beschreib mal möglichst wenig konfus, was du machen willst. Vielleicht am Beispiel einer (deiner) Anwendung, die auf eine DB zugreifen soll.


----------



## von Spotz (29. Dez 2021)

"die .jar" Datei die von Maven aus dem Microservice Teilprojekt erstellt wird ?

Tut mir Leid, ist daran etwas nicht korrekt?


----------



## temi (29. Dez 2021)

von Spotz hat gesagt.:


> Tut mir Leid, ist daran etwas nicht korrekt?


Weiß ich nicht, ich hab ja nicht verstanden was du meinst 

Also, was ich jetzt verstanden habe ist, dass du mehrere Projekte hast, die am Schluss jeweils in einem eigenen Container laufen sollen (Microservices). Dazu hast du dann noch weitere Container mit einer Datenbank und Kafka usw. Ist das richtig?

EDIT: Es geht dir also darum, dass du, wenn du an Service xy entwickelst und diesen während der Entwicklung testest (compilierst und startest), dass all die für die gesamte Anwendung benötigten weiteren Services in Containern automatisch gestartet werden. Ist das richtig?


----------



## von Spotz (29. Dez 2021)

temi hat gesagt.:


> Weiß ich nicht, ich hab ja nicht verstanden was du meinst
> 
> Also, was ich jetzt verstanden habe ist, dass du mehrere Projekte hast, die am Schluss jeweils in einem eigenen Container laufen sollen (Microservices). Dazu hast du dann noch weitere Container mit einer Datenbank und Kafka usw. Ist das richtig?
> 
> EDIT: Es geht dir also darum, dass du, wenn du an Service xy entwickelst und diesen während der Entwicklung testest (compilierst und startest), dass all die für die gesamte Anwendung benötigten weiteren Services in Containern automatisch gestartet werden. Ist das richtig?


Hallo temi,
ich möchte ersteinmal sagen, daß ich sehr dankbar für eure Antworten bin. Ich selber bin Anfänger sowohl was DDD (Domain Driven Design), Microservices, Java und die üblichen IDEs/BuildManager und was Container angeht. Daher bitte ich um Verzeihung, wenn ich das, worauf ich hinaus möchte, vielleicht noch nicht so formal ausdrücken kann, wie es vielleicht angemessen wäre. Ich gebe mir allerdings Mühe. Außerdem kenne ich nicht euren Hintergrund, ich weiß nicht, ob ihr etwa eure Applikationen als Microservices entwickelt und Container benutzt. Es war jedenfalls z.B. zumindest schon einmal ein großer Aufwand, die grundlegenden Rollen, Funktionen, Aufgaben und Pattern von Microservices zu erkunden, weil es nirgendwo eine Liste oder sogar eine mehr oder weniger erschöpfende Liste gibt. Die Terminologie und die Konventionen sind beim Programmieren immer die größte Hürde. Ansonsten unterscheidet sich zwischen, ich sage mal, Ruby und Python nicht viel und zwischen Java, C# und C++. Mehr allerdings zu Programmiersprachen wie LISP oder Haskell. Und ihr habt wahrscheinlich jahrelange Erfahrung in der Java-Terminologie und den Konventionen. Also wie gesagt, kann ich nur um Nachsicht bitten, falls der Fehler auf meiner Seite liegt. Ich hoffe, daß man über alles reden ḱann und sich das Forum nicht plötzlich als stackoverflow.com entpuppt, wo man selbst dann angeranzt wird, wenn man berechtigte Fragen stellt, nochmal angeranzt wird, wenn von den Schlauköpfen keiner eine Antwort weiß, und ein letztes Mal angeranzt wird, wenn man nach zwei Tagen selber auf die Lösung kommt (weil bash einfach an einer Stelle verbuggt ist) und dafür dann nochmal angeranzt wird 

Ich gehe im nächsten Posting auf den Inhalt von Deinem letzten Post ein. Nochmal vielen Dank für die Hilfsbereitschaft.


----------



## temi (29. Dez 2021)

Ach, mach dir mal keinen Kopf. Es ist noch kein Meister vom Himmel gefallen. Erst mal geht es nur darum herauszufinden, was du genau meinst und machen willst. Erst dann kann man eine sinnvolle Antwort geben. Ich bin mir allerdings nicht sicher, ob ich derjenige bin, der das kann, da ich weder mit Maven, noch mit Microservices viel am Hut habe.


----------



## von Spotz (29. Dez 2021)

temi hat gesagt.:


> Weiß ich nicht, ich hab ja nicht verstanden was du meinst
> 
> Also, was ich jetzt verstanden habe ist, dass du mehrere Projekte hast, die am Schluss jeweils in einem eigenen Container laufen sollen (Microservices). Dazu hast du dann noch weitere Container mit einer Datenbank und Kafka usw. Ist das richtig?
> 
> EDIT: Es geht dir also darum, dass du, wenn du an Service xy entwickelst und diesen während der Entwicklung testest (compilierst und startest), dass all die für die gesamte Anwendung benötigten weiteren Services in Containern automatisch gestartet werden. Ist das richtig?


Da ein Microservice aus mehreren domain services, also jeweils einem Projekt pro domain service, besteht, und jeder Service seine binären Abhängigkeiten hat, welchen wiederum ein Container mit bestimmten docker-images (im Fall von Docker, mit Kubernetes habe ich mich noch nicht beschäftigt) mit den binären Abhängigkeiten und einem Dockerfile als Konfigurationsdatei entspricht, soll das per Projekt durch "Run As..." erzeugte .jar Archiv am besten automatisch, wie Du korrekt sagst, von der IDE containerisiert werden und im Container gestartet werden.

Und dazu gehört dann möglicherweise auch, daß ich von den Teilprojekten des Microservice eine Auswahl von Services treffe, die ich, so wie oben beschrieben containerisiert, miteinander testen möchte. Das ganze dann eben granular, sodaß jedem Projekt, ebenfalls automatisch, der ihm spezifisch zukommende Container zugewiesen wird.

Ich hoffe das war jetzt halbwegs verständlich.


----------



## kneitzel (29. Dez 2021)

temi hat gesagt.:


> EDIT: Es geht dir also darum, dass du, wenn du an Service xy entwickelst und diesen während der Entwicklung testest (compilierst und startest), dass all die für die gesamte Anwendung benötigten weiteren Services in Containern automatisch gestartet werden. Ist das richtig?


Nach meinem Verständnis soll das Testen aber dann auch in einem Container stattfinden. (Weshalb meine Bemühungen vorab ins Leere liefen und der TE und ich aneinander vorbei geredet haben ... zumindest ist das mein aktuelles Verständnis.)

Und da wäre meine Überlegung aktuell: Dies ist doch recht spezifisch bezüglich Entwicklerumgebung / IDE. Wäre es da nicht sinnvoll, das über ein Script zu machen, das eben die notwendigen Container deployed / startet um dann am Ende den Java Prozess, den man debuggen möchte, startet (mit entsprechendem Debugging übers setze, also zum einen erfolgt der Start mit entsprechenden Parametern und zum anderen wird der Port entsprechend weiter geleitet.



von Spotz hat gesagt.:


> wo man selbst dann angeranzt wird


Also wir sind hier eigentlich relativ hart im nehmen und schnauzen andere nicht an. Ausnahmen gibt es natürlich auch, aber das ist dann eigentlich nur, wenn Leute eigentlich keine Hilfe wollen. Oder so Missverstände eskalieren leicht (Aber Du warst ja auch mit mir sehr geduldig - aber ich wollte Dich ebenso wenig ärgern wie Du mich).


----------



## temi (29. Dez 2021)

von Spotz hat gesagt.:


> und jeder Service seine binären Abhängigkeiten hat


Was genau verstehst du denn unter "binäre Abhängigkeiten"?


----------



## von Spotz (29. Dez 2021)

temi hat gesagt.:


> Was genau verstehst du denn unter "binäre Abhängigkeiten"?


Du hast doch selber gesagt, daß das, was Maven an Abhängigkeiten lädt, regelmäßig die _Treiber für_, etwa die Datenbank, aber nicht die Datenbank selbst sind. Auch Kafka als Message Broker etwa ist kompilierter Maschinen/Bytecode. Ich kenne mich mit Containern noch nicht gut aus, aber ich denke, der Container würde sogar das Betriebssystem Image und das JavaVM Image enthalten. Ich habe eben von Kafka gesprochen. Das gibt es nicht als debian Paket, sondern nur als fertig kompiliertes Archiv, das ich persönlich nach /usr/local/kafka entpackt und zu $PATH hinzugefügt habe. Aber man kann grob sagen: Alles, was man über den Paketmanager installieren kann bzw. was es eben als docker-image (siehe https://hub.docker.com/) gibt.


----------



## von Spotz (29. Dez 2021)

Hallo lieber Kneitzel,
ich wollte keinesfalls sagen, daß man hier angeranzt wird. Die freundliche Atmosphäre hier ist ja das Schöne im Vergleich zu stackoverflow 

Und ja, wahrscheinlich ist die einzige Lösung ein Skript. Außer man kann irgendwie aus Java heraus Docker Swarm (ist doch der Container Orchestrator für Docker Container, oder?) ansprechen und konfigurieren. *Daher stelle ich an dieser Stelle noch einmal meine Frage in der Hoffnung, daß die Frage legitim ist: Ist ein Container Orchestrator ein Service, der zu dem Microservice gehört und als solcher aus Java angesprochen werden kann oder nicht?* Außerdem sollte zu dem Zweck das Microservice Projektmanagement mit dem Container Projektmanagement harmonisiert werden, sodaß das target-Verzeichnis für die aus den Microservice-Teilprojekten gepackten .jar Dateien gleich in das diesen jeweils entsprechende Container-Verzeichnis gelegt wird, so wie die Paketstruktur in Java äquivalent zur Ordnerstruktur ist.

Tut mir Leid, ich bin heute / gerade recht erschöpft. Wahrscheinlich werde ich die Antwort morgen nochmal verbessern/überarbeiten.

Alles Gute und bis dann!
von Spotz


----------



## mrBrown (30. Dez 2021)

von Spotz hat gesagt.:


> *Daher stelle ich an dieser Stelle noch einmal meine Frage in der Hoffnung, daß die Frage legitim ist: Ist ein Container Orchestrator ein Service, der zu dem Microservice gehört und als solcher aus Java angesprochen werden kann oder nicht?*


NEIN!

Genauso wie der Cellist dem Dirigenten nicht sagt, was er machen soll, sagt der Microservice dem Orchestartor nicht, was er machen soll.


Um mal bei deinem Beispiel zu bleiben: In Java geschriebener Microservice, der mehrere externe Abhängigkeiten hat, z.B. MySQL und Kafka.

Für automatisierte Tests kümmert sich das "Framework" darum, dass Abhängigkeiten passend gestartet werden. Entweder auf Unit-Test-Ebene mit zb Testcontainers, was dann nötige Container on the fly startet, oder Maven, was Abhängigkeiten vor den Test-Phasen starten kann, oder deine Build-Pipeline, die das ganze vor den Tests passend startet. Wichtig ist: deine getestete Anwendung selbst macht das nicht!

Für manuelle Tests musst du das eben selbst starten. Entweder per Hand jede Abhängigkeit starten, oder per Skript, oder per IDE (wenn die unterstützen, dass vor dem Start automatisch irgendwas anderes gemacht wird, was dann zB der Start der Abhängigkeiten sein kann). Deine Anwendung macht das aber nicht selbst (zumindest nicht so, dass sie das weiß, moderne Frameworks könne Abhängigkeiten bei lokalen Tests mittlerweile transparent on the fly starten).


Wenn die Abhängigkeiten in Containern laufen, wird das ganze deutlich einfacher, weil nur noch der Container gestartet werden muss. Deine eigene Anwendung muss dafür aber natürlich nicht in einem Container laufen!
Prinzipiell ist aber egal, wie die Abhängigkeiten laufen, die können auch nativ auf dem Host laufen, oder irgendwo Remote – sie müssen nur irgendwie gestartet werden können oder passend erreichbar sein.


----------



## LimDul (30. Dez 2021)

Ich glaube, dass dir momentan noch die Begrifflichkeiten und Zuständigkeiten nicht ganz klar sind.

Vorneweg - ich kenne mich mit dem Container Zeugs nur auf einer abstrakten/theoretischen Ebene aus, weil ich noch mehr im schwergewichtigen Applicationserver Umfeld (JBoss und Co) unterwegs bin. Daher gerne Korrekturen, wenn ich was falsch darstelle.

Dein Java Programm - was über Maven seine Abhängigkeiten managed - ist erst mal nichts anderes als das. Ein Programm, was zusammen mit der Java VM gestartet werden kann. Entweder als ein großes Jar oder ein jar + x Jars als Abhängigkeit. Die Abhängigkeiten können ein DB Treiber sein, Kafka-Bibliotheken etc.

Was hier noch keinerlei Rolle spielt:
* Die laufende Kafka Instanz / Kafka Binarys 
* Die laufende Datenbank / Datenbank Binarys

Die werden für das Programm und insbesondere den Start des Programms *nicht* benötigt. Das Programm nutzt die Bibliotheken um ggf. eine Verbindung zu einem Kafka-Server oder einem DB-Server aufzumachen. Wo der aber läuft ist dem Programm quasi vollkommen egal. In irgendeiner Form wird das eine Konfiguration bestehen aus IP, Port, User & Passwort sein.

Container kommen erst danach ins Spiel, wenn es darum geht, wie betreibt man diesen ganzen Zoo an Anwendungen. Den insbesondere im Sinne von Microservices hast du nicht eine Java-Anwendung, sondern vielleicht 10 Java Anwendungen, die du vielleicht auch hochverfügbar laufen lassen willst. Und da sind Container mit ein Mittel. Ein Container sorgt dafür, dass ein Container *eine* Anwendung enthält und in der Container-Umgebung lauffähig ist. Das Programm selber bekommt davon nichts mit. Das ist Software drum rum, die du konfigurierst, wie das entstandene Programm in einen Container verpackt wird. Und da kann man da sich überlegen. Packe ich DB + Programm in einen eigenen Container? Oder nicht? Gibt für alles Gründe dafür und dagegen.


----------



## temi (30. Dez 2021)

von Spotz hat gesagt.:


> Du hast doch selber gesagt, daß das, was Maven an Abhängigkeiten lädt, regelmäßig die _Treiber für_, etwa die Datenbank, aber nicht die Datenbank selbst sind. Auch Kafka als Message Broker etwa ist kompilierter Maschinen/Bytecode. Ich kenne mich mit Containern noch nicht gut aus, aber ich denke, der Container würde sogar das Betriebssystem Image und das JavaVM Image enthalten. Ich habe eben von Kafka gesprochen. Das gibt es nicht als debian Paket, sondern nur als fertig kompiliertes Archiv, das ich persönlich nach /usr/local/kafka entpackt und zu $PATH hinzugefügt habe. Aber man kann grob sagen: Alles, was man über den Paketmanager installieren kann bzw. was es eben als docker-image (siehe https://hub.docker.com/) gibt.


Darauf wollte ich hinaus. "Binäre Abhängigkeiten" sind für mich irgendwelche Bibliotheken für den DB-Zugriff, für Kafka (nicht der Kafka-Server selbst!), Logging und weiß der Teufel noch was alles. Diese werden in deinem Programm mittels Import-Anweisungen eingebunden und von deinem Programm verwendet. Dies kann Maven/Gradle alles herunterladen und entsprechend bereitstellen. Sind sie nicht vorhanden, wird dein Programm nicht compilieren/starten.

Daneben hat dein Programm dann noch "externe Abhängigkeiten", wie @mrBrown es genannt hat. Das ist dann der DB-Server, der Kafka-Server, andere Services, usw. Das Programm kannst du ohne diese externen Abhängigkeiten compilieren und starten. Allerdings wird es dann natürlich nicht funktionieren und abhängig davon, wie du z. B. auf das Fehlen des DB-Servers reagierst, sich auch wieder beenden.

Das war jetzt mehr oder weniger, was meine beiden Vorredner schon gesagt haben. Aber ich wollte auch noch auf deine Erwiderung auf meine Frage geantwortet haben. Es ist sehr wichtig, das wir wissen, wovon wir sprechen und was damit gemeint ist.


----------



## LimDul (30. Dez 2021)

LimDul hat gesagt.:


> Was hier noch keinerlei Rolle spielt:
> * Die laufende Kafka Instanz / Kafka Binarys
> * Die laufende Datenbank / Datenbank Binarys


Um das hier von @temi abzugrenzen - was ich hier mit Binarys meine - Das Kafka Programm, inklusive Executable (analog zu DB) - nicht die Abhängigkeiten, die ein Jar sind (die auch Binär sind)


----------



## temi (30. Dez 2021)

LimDul hat gesagt.:


> Um das hier von @temi abzugrenzen - was ich hier mit Binarys meine - Das Kafka Programm, inklusive Executable (analog zu DB) - nicht die Abhängigkeiten, die ein Jar sind (die auch Binär sind)


Ich bin mir auch nicht sicher, ob die direkten Abhängigkeiten als binäre Abhängigkeiten bezeichnet werden. Gibt es da eine begriffliche Unterscheidung?


----------



## von Spotz (1. Jan 2022)

Hallo LimDui,



			
				LimDui hat gesagt.:
			
		

> Ich glaube, dass dir momentan noch die Begrifflichkeiten und Zuständigkeiten nicht ganz klar sind.



Öh, ja, das schreibe ich ja bereits oben an temi. Siehe https://www.java-forum.org/thema/maven-und-andere-abhaengigkeiten.195162/#post-1290296

Ich bin Java-Einsteiger erstmal um der Entwicklung Microservices willen (vielleicht auch ANTLR) und das Problem scheint ja auch so gestaltet zu sein, daß auch ihr Experten da nicht eben eine Lösung aus dem Ärmel schüttet.

Aber ich bin sehr froh darüber, daß wir - ohne daß der Noob, also ich, "angeranzt" wurde, wie es vielleicht auf stackoverflow der Fall wäre (s.o.) - zumindest jetzt soweit gekommen ist, daß das Problem klar ist. Vielleicht möchte das noch einmal jemand konzise und formal korrekt zusammenfassen. Dann sollte man dies in den Eröffnungspost setzen, damit jemand anderes nicht erst bis hierhin lesen muss, um das Thema von dem Topic zu verstehen. Wäre super!

Aber hier scheint ja in den letzten Posts unter den Experten Uneinigkeit über den richtigen Begriff für das, was ich meine: Soll man dazu "binäre Abhängigkeiten" oder "externe Abhängigkeiten" sagen? Und zu dem anderen? "Treiber" ? @LimDui: Ich hatte mich mit dem Begriff "Treiber" in den letzten Posts zur Bezeichnung der java-internen (meinetwegen binären) Abhängigkeiten (zur Unterscheidung zu laufender Kafka Instanz, laufender DB-Instanz) an dem Sprachgebrauch von temi angelehnt.

Frohes neues Jahr!
von Spotz


----------



## temi (1. Jan 2022)

Der Begriff "Treiber" war eher eine Art Notlösung, die für eine DB ganz in Ordnung ist. Diese (binären) Abhängigkeiten können allerdings ja alles mögliche sein. Das ist einfach alles, was du an Bibliotheken in deine Software integrieren kannst. Zudem kannst du noch unterscheiden, ob die Bibliothek nur zum Testen benötigt wird (Mocking, Test-Frameworks, usw.) oder auch im "normalen" Betrieb, wie Logging, DI-Container, ORM-Frameworks, DB-Zugriffskomponenten, usw.). Ich würde das alles unter dem Begriff "Abhängigkeiten" zusammenfassen.

Das dein Programm auch eine laufende DB-Instanz und weitere Services benötigt, würde ich eher zur Infrastruktur zählen.

Ansonsten hat @mrBrown doch allerlei aufgezählt, was du machen kannst.


----------



## mrBrown (1. Jan 2022)

von Spotz hat gesagt.:


> das Problem scheint ja auch so gestaltet zu sein, daß auch ihr Experten da nicht eben eine Lösung aus dem Ärmel schüttet.


Das Problem stellt eher kein wirkliches Problem dar, es gibt X verschiedene Möglichkeiten, und je nach persönlicher Präferenz und Anforderungen sucht man sich eine aus.



von Spotz hat gesagt.:


> Aber hier scheint ja in den letzten Posts unter den Experten Uneinigkeit über den richtigen Begriff für das, was ich meine: Soll man dazu "binäre Abhängigkeiten" oder "externe Abhängigkeiten" sagen? Und zu dem anderen? "Treiber" ?


Das „Problem“ ist in dem Fall eher, dass es alles Abhängigkeiten sind, nur auf unterschiedlichen Ebenen.
Keine Ahnung, ob es da sinnvolle feste Begriffe für gibt, von daher umschreibt man das einfach möglichst passend für den jeweiligen Fall.


----------



## von Spotz (1. Jan 2022)

Naja, es wird muss ja einen Sprachgebrauch geben, der eindeutig zwischen Bibliotheken als binären Abhängigkeiten einerseits und "externen binären Abhängigkeiten" wie eben laufende Kafka-Server und Datenbanken eindeutig reflektiert. 

Ich gehe später noch auf Deine Posts ein DocBrown 

Alles Gute!
vonSpotz


----------



## LimDul (1. Jan 2022)

von Spotz hat gesagt.:


> Naja, es wird muss ja einen Sprachgebrauch geben, der eindeutig zwischen Bibliotheken als binären Abhängigkeiten einerseits und "externen binären Abhängigkeiten" wie eben laufende Kafka-Server und Datenbanken eindeutig reflektiert.
> 
> Ich gehe später noch auf Deine Posts ein DocBrown
> 
> ...


Das Problem ist - den laufenden Kafka-Server bezeichnet man normalerweise nicht als Abhängigkeiten. Das sind einfach Dinge, die angesprochen werden. Da ist eigentlich das Wort "Abhängigkeiten" falsch.


----------



## temi (1. Jan 2022)

von Spotz hat gesagt.:


> DocBrown


 *vs* 

Sorry, musste sein


----------



## von Spotz (1. Jan 2022)

LimDul hat gesagt.:


> Das Problem ist - den laufenden Kafka-Server bezeichnet man normalerweise nicht als Abhängigkeiten. Das sind einfach Dinge, die angesprochen werden. Da ist eigentlich das Wort "Abhängigkeiten" falsch.


Applikationen in Microservice Architektur geschrieben und Container gehören zusammen. Sonst macht das ganze keinen Sinn. Gut, Asynchronizität bekommt man auch in einer Saga über einen Broker, aber oben drauf kommt ja noch die Parallelisierung durch Container-Cluster. Es ist nur folgerichtig, die Abhängigkeiten von Microservice domain services in Form eines docker-image (im Fall, daß man Docker benutzt) anzugeben ! Warum sind das keine "externen binären Abhängigkeiten" ?


----------



## kneitzel (1. Jan 2022)

von Spotz hat gesagt.:


> Applikationen in Microservice Architektur geschrieben und Container gehören zusammen. Sonst macht das ganze keinen Sinn. Gut, Asynchronizität bekommt man auch in einer Saga über einen Broker, aber oben drauf kommt ja noch die Parallelisierung durch Container-Cluster. Es ist nur folgerichtig, die Abhängigkeiten von Microservice domain services in Form eines docker-image (im Fall, daß man Docker benutzt) anzugeben ! Warum sind das keine "externen binären Abhängigkeiten" ?


Also aus meiner Sicht wirfst Du da extrem viel durcheinander. Microservice Architektur ist lediglich - der Name verrät es - eine Architektur, die vorgibt, wie etwas aufgebaut wird. Eine Applikation, die dieser Architektur folgt ist somit weiterhin schlicht eine Applikation. Nur weil Microservices oft in Containern bereit gestellt werden gibt es da nicht dieses Zusammengehörende. Ein Microservice muss nicht in einen Container und ein Container muss keinen Microservice beinhalten. Das sind einfach zwei Dinge die zusammen kommen können, aber es gibt da keinen wirklichen Zusammenhang.

Und wenn Du mehrere Instanzen laufen lässt (Was du hier als Parallelisierung ansprichst) dann spielt es absolut keine Rolle, wie Du dies laufen lässt. Da ist es egal, wie Du es verpackst (also z.B. in Container) und wie Du es laufen lässt (Ob da nun ein Cluster dahinter steckt oder irgend etwas anderes). Statt eines Clusters kann es auch nur ein Node sein. Oder ganz ohne Container lässt du es x mal auf n Systemen laufen. Du kannst das jar auch auf einem System 10 mal laufen lassen. Oder 1 Mal auf 10 Systemen. Die Container sind streng genommen nur eine Virtualisierungsschicht zusammen mit einer Verwalung. Dies macht es dann das Management deutlich einfacher.

Wie Du nun Abhängigkeiten benennst / angibst ist dabei auch nebensächlich. Wenn Du eine spezifische Technologie einsetzt, dann solltest Du natürlich eine Beschreibung wählen, die von der Technology verstanden wird oder das da irgendwie genutzt werden kann. 

Und bei


von Spotz hat gesagt.:


> Warum sind das keine "externen binären Abhängigkeiten" ?


sind wir bei dem Punkt, dass hier keine geeigneten Begriffe verwendet werden. Und ich habe Probleme, Dir zu folgen, weil Du aus meiner Sicht extrem viel durcheinander wirfst.


----------



## Oneixee5 (1. Jan 2022)

Ich würde das zur Infrastruktur zählen.


----------



## LimDul (1. Jan 2022)

Ich hab so etwas das Gefühl, dass @von Spotz gerade versucht ein Schloss zu bauen, aber noch nicht vollständig verstanden hat, wie man ein Fundament legt. 

So ist es mir übrigens vor ewigen Zeiten auch gegangen, als ich nach einem Einstieg in Java EE gesucht habe - zu viele Technologien und Begriffe (EJB, JMS, JPA, ....) die alle wieder auf was anderes verwiesen oder erwähnten und man keinen Anpack hatte, wo man nun anfängt.

Was ich dir daher raten würde:
Vergiss das ganze Zeug über Microservices, Container, Kafka, Datenbanken und Co für eine Weile und beschäftige dich mit den Basics. Java mit Maven. Ein einfaches Hello-World Java Maven Projekt anlegen und damit rumspielen. Dann man weitere Libs einbinden, z.B. apache commons. Um einfach mal ein Gefühl dafür zu bekommen, was macht Maven eigentlich. Und dann sukzessive die nächsten Schritte.


----------

