Was ist SSH?

Es ermöglicht die sichere Kommunikation zwischen zwei Systemen über ein unsicheres Netzwerk wie das Internet. Es bietet eine verschlüsselte Sitzungsprotokollierung und Dateiübertragung, wodurch es zu einer idealen Lösung für die Fernadministration von Servern und sicheres Surfen über unsichere Netzwerke wird.

Die Entstehung von SSH

SSH entstand Anfang der 1990er Jahre. Tatu Ylönen, ein Forscher aus Finnland, entwickelte es als Reaktion auf einen Passwort-Sniffing-Angriff auf sein Universitätsnetzwerk. SSH1, die erste Version, erschien 1995 und fand rasch breite Akzeptanz. Um Mängel in SSH1 zu adressieren, entwickelte man SSH2 mit verbesserten Sicherheitsmechanismen. Heute verwenden fast alle modernen Systeme SSH2.

Anwendung von SSH

Es dient mehreren Zwecken:

1. Fernzugriff: Administratoren nutzen es, um sich sicher mit einem Remote-Server zu verbinden und Befehle auszuführen.
2. Dateiübertragung: Mit SCP (Secure Copy Protocol) und SFTP (Secure File Transfer Protocol) lassen sich Dateien verschlüsselt übertragen.
3. Port-Weiterleitung: Man kann lokale und entfernte Ports weiterleiten und so sichere verschlüsselte Tunnel für andere Anwendungen bereitstellen.

Beispiel: Verbindung zu einem Remote-Server:

ssh benutzername@serveradresse

Einrichtung

Um es nutzen zu können, installiert man den OpenSSH-Server und -Client. Viele moderne Betriebssysteme, wie Linux-Distributionen und macOS, liefern bereits vorinstallierte Tools.

Beispiel: Installation von OpenSSH unter Ubuntu:

sudo apt update sudo apt install openssh-server

Nach der Installation startet der Dienst automatisch. Man kann den Status mit folgendem Befehl prüfen:

sudo systemctl status ssh

Zur Sicherheit sollte man einige Einstellungen in der Konfigurationsdatei anpassen:

1. Port ändern: Den Standardport 22 ändern, um Basisangriffe zu vermeiden.
2. Root-Login verbieten: Den Root-Zugriff über SSH deaktivieren.
3. Zugriff einschränken: Nur bestimmten Benutzern den Zugriff erlauben.

Diese Änderungen nimmt man in der Datei /etc/ssh/sshd_config vor und startet anschließend den SSH-Dienst neu.

Abschließend sollte man sich immer um regelmäßige Sicherheitsupdates kümmern, um das System und SSH gegen bekannte Schwachstellen abzusichern.

Fazit

SSH hat sich seit seiner Entstehung als ein unverzichtbares Tool für sichere Kommunikation im Netz etabliert. Mit dem richtigen Know-how und einigen Sicherheitsvorkehrungen bietet es eine robuste und sichere Methode für die Fernadministration und Dateiübertragung.

Der Beitrag SSH (Secure Shell) – Sichere Kommunikation, jederzeit und überall erschien zuerst auf CEOsBay.

Geschichte des Apache-Webservers

Die Entstehung von Apache geht zurück auf die frühen 1990er Jahre. Damals suchten einige Webentwickler nach einer Alternative zum damals populären NCSA HTTPd-Server, der von der National Center for Supercomputing Applications entwickelt wurde. Der Name „Apache“ leitet sich von „A Patchy Server“ ab, was darauf hinweist, dass der ursprüngliche Code aus einer Reihe von Patches zum NCSA HTTPd bestand.

Das Apache-Entwicklerteam, zu dem Personen wie Rob McCool und Brian Behlendorf gehörten, veröffentlichte die erste offizielle Version 1995. Seitdem hat Apache stetige Weiterentwicklungen erlebt und stellt heute ein führendes Open-Source-Projekt dar, das die Apache Software Foundation verwaltet.

Einrichtung des Apache-Webservers

Apache lässt sich auf vielen Betriebssystemen, einschließlich UNIX, Linux und Windows, installieren. Der Apache-Webserver ist bereits in macOS eingebaut, allerdings standardmäßig deaktiviert. Dazu aber im Anschluss mehr. Für eine einfache Installation auf einem Debian-basierten System, wie Ubuntu, verwendet man beispielsweise folgende Befehle:

sudo apt update sudo apt install apache2

Nach der Installation läuft der Webserver und kann über einen Webbrowser mit der URL „http://localhost“ erreicht werden.

Konfiguration

Der Apache-Webserver bietet eine Vielzahl von Konfigurationsoptionen, die in der Hauptkonfigurationsdatei /etc/apache2/apache2.conf zu finden sind. Einzelne Website-Konfigurationen lassen sich in /etc/apache2/sites-available/ erstellen und mit dem Tool a2ensite aktivieren.

Auf dem Mac

Der Apache-Webserver ist bereits in macOS eingebaut, allerdings standardmäßig deaktiviert. Für diejenigen, die Apache auf einem Mac nutzen möchten, hier eine Schritt-für-Schritt-Anleitung zur Aktivierung und Einrichtung:

Apache auf macOS aktivieren und konfigurieren

1. Apache starten: Im Terminal gibt man den folgenden Befehl ein:bashCopy codesudo apachectl startNachdem man den Befehl ausgeführt hat, kann man über den Webbrowser über die URL „http://localhost“ überprüfen, ob Apache läuft. Es sollte eine Standard-Begrüßungsseite von Apache erscheinen.
2. Dokumentenverzeichnis bestimmen: Standardmäßig verwendet Apache das Verzeichnis /Library/WebServer/Documents/ als Web-Wurzelverzeichnis. Inhalte, die in diesem Verzeichnis platziert sind, kann man über den Webbrowser erreichen.
3. Apache-Konfigurationsdatei bearbeiten: Die Hauptkonfigurationsdatei von Apache auf macOS befindet sich unter /etc/apache2/httpd.conf. Um diese Datei zu bearbeiten, kann man einen Texteditor wie nano verwenden:bashCopy codesudo nano /etc/apache2/httpd.confIn dieser Datei kann man verschiedene Einstellungen vornehmen, z.B. die Aktivierung von PHP, die Definition von Virtual Hosts oder die Anpassung des Dokumentenverzeichnisses.
4. PHP aktivieren (optional): Wenn PHP auf dem Mac installiert ist und man es mit Apache verwenden möchte, kann man dies in der httpd.conf-Datei aktivieren. Dazu muss die Zeile, die mit #LoadModule php beginnt, gesucht und das # am Anfang der Zeile entfernt werden. Nach dem Speichern der Datei muss man Apache neu starten, um die Änderungen zu übernehmen.
5. Apache neu starten: Jedes Mal, wenn man Änderungen an der Konfigurationsdatei vornimmt, muss man Apache auch neu starten. Dies kann mit dem folgenden Befehl erfolgen:bashCopy codesudo apachectl restart
6. Automatischer Start von Apache: Wenn man möchte, dass Apache automatisch beim Hochfahren des Macs startet, kann man den folgenden Befehl verwenden:bashCopy codesudo launchctl load -w /System/Library/LaunchDaemons/org.apache.httpd.plist

Abschließende Anmerkungen

Obwohl macOS einen eingebauten Apache-Server enthält, ziehen es einige Entwickler vor, Tools wie MAMP (Habe ich in der Vergangenheit verwendet aber heute eher nicht mehr. Evtl. schreibe ich noch einen Beitrag darüber) oder Homebrew zu verwenden, um eine individuellere Entwicklungsumgebung zu schaffen. Diese Tools bieten oft eine einfachere Einrichtung und Konfiguration, insbesondere wenn auch andere Dienste wie MySQL oder PHP in spezifischen Versionen benötigt werden.

Best Practices und zu beachtende Punkte

1. Sicherheit: Es ist immer dafür zu sorgen, dass der Webserver auf dem neuesten Stand ist, um Sicherheitslücken zu schließen. Zusätzlich empfiehlt sich die Installation von mod_security als Web Application Firewall.
2. Performance: Für Websites mit hohem Traffic sollte man Module wie mod_cache und mod_expires verwenden, um Inhalte zu cachen und um die Ladezeiten zu reduzieren.
3. SSL/TLS: In der heutigen Zeit ist es unerlässlich, Websites über HTTPS bereitzustellen. Mit Tools wie Let’s Encrypt lassen sich kostenlose SSL-Zertifikate generieren und mit Apache verwenden.
4. Module: Apache bietet eine Vielzahl von Modulen, die zusätzliche Funktionalitäten bereitstellen. Es ist genau zu überlegen, welche Module man benötigt, um unnötige Ressourcenbelastungen zu vermeiden.

Fazit

Der Apache-Webserver ist nicht nur ein Stück Internetgeschichte, sondern auch heute noch ein leistungsstarkes Tool für Webentwickler und Administratoren. Mit dem richtigen Wissen und den passenden Best Practices lässt sich Apache optimal einsetzen und bietet eine solide Grundlage für nahezu jede Webanwendung.

Der Beitrag Apache-Webserver erschien zuerst auf CEOsBay.

MapStruct nutzt dabei die Annotationen, die auf den Java-Objekten angebracht sind, um automatisch Mapping-Code (Bean-Mappings) zu generieren. Das Framework generiert dabei standardmäßig Mappings zwischen Objekten mit gleichem Namen und Typ, es können aber auch eigene Mappings definiert werden. Dabei können auch komplexere Mappings erstellt werden, beispielsweise wenn Attribute in den Quell- und Zielobjekten unterschiedliche Namen haben oder wenn sie unterschiedliche Typen haben.

MapStruct ist sehr einfach zu verwenden und erfordert nur eine minimale Konfiguration. Es integriert sich nahtlos in das Build-System, da es als Annotation Processor fungiert und beim Kompilieren des Codes aufgerufen wird. Das Framework ist relativ schnell und hat einen geringen Overhead, da es keine Laufzeit-Abhängigkeiten hat.

Vorteile auf einem Blick

• Schnelle Ausführung durch Verwendung einfacher Methodenaufrufe anstelle von Reflexion (Bedeutet: Ein Programm kennt seine eigene Struktur und kann diese modifizieren)
• Kompilierzeit-Typensicherheit. Nur Objekte und Attribute, die einander zugeordnet sind – Es findet keine versehentliche Zuordnung einer Auftragsentität zu einem Kunden-DTO statt.
• In sich geschlossener Code – keine Laufzeit-Abhängigkeiten
• Eindeutige Fehlerberichte zur Erstellungszeit, wenn: 
  • Mappings unvollständig sind (Wenn nicht alle Zieleigenschaften gemappt sind)
  • Mappings fehlerhaft sind (Wenn es keine geeignete Mapping-Methode oder Typkonvertierung findet)
• Leicht zu debuggender Mapping-Code (Oder manuell editierbar, z. B. im Falle eines Fehlers im Generator)

Fazit

Zusammenfassend ist MapStruct ein leistungsfähiges und einfach zu bedienendes Framework, das die Entwicklung von Mapping-Code vereinfacht und beschleunigt. Vor allem, weil das Übertragen von Daten zwischen Objektmodellen meist eine wiederkehrende Aufgabe bei der Anwendungsentwicklung ist. Es ist eine gute Wahl, wenn man schnell und effizient Mapping-Funktionalitäten in Anwendungen integrieren möchte. Man kann es in Befehlszeilen-Builds (Maven, Gradle usw.) als auch in der bevorzugten IDE wie z.B. IntelliJ oder Eclipse verwenden.

Der Beitrag MapStruct – Schnelle und sichere Objektmapper für saubere und wartungsfreundliche Java-Anwendungen erschien zuerst auf CEOsBay.

Maven vereinfacht den Softwareerstellungsprozess, bietet ein einheitliches System für die Entwicklerarbeit, hochwertige Projektinformationen, Richtlinien für das Festlegen von Best Practices und erleichtert die Migration zu neuen Funktionen durch mehr Transparenz. Es beschreibt sowohl, wie Software gebaut wird, als auch deren Abhängigkeiten. Apache hilft sowohl bei der Verwaltung von Projekten und dient als Tool zum Verständnis. Es hilft also dabei, den Zustand eines Projekts zu organisieren und relativ schnell darzustellen.

Primär wird das Programm von Entwicklern und Projektmanagern bei Java-Anwendungsprojekten verwendet. Das Tool kann nützlich sein, um den Zustand eines Projektes auf einem Blick für technisch weniger versierte Personen, wie Führungspersönlichkeiten und Investoren, zusammenzufassen und gleichzeitig, um einige Prozesse bei der Softwareentwicklung zu automatisieren.

Maven basiert auf dem Objektmodell. Projekte werden als eine Pom.xml-Datei gespeichert. Das Tool verwaltet Projekt-Builds, Reportings und Dokumentationen aus einer zentralen XML-Informationsbasis. Mit der Standard-Plug-in-Architektur kann man es über den Standard-Input mit so gut wie jeder Anwendung nutzen und kollaborieren. Es vereinfacht den Prozess für das Erstellen von Java-Anwendungen erheblich, sodass der Nutzer den Status des Projektes viel einfacher einschätzen kann.

Der Name Maven kommt aus dem Jiddischen und bedeutet so viel wie „Sammler des Wissens“.

Kurze Zeitreise

Maven entstand in der Apache Software Foundation aus Frust über den Build-Prozess von Turbine. Es wurde bald zum Top-Level-Projekt aufgrund der Notwendigkeit, die Builds der vielen unterschiedlichen Projekte der Apache Software Foundation möglichst zu vereinheitlichen und somit auch zu vereinfachen.

Durch die vereinheitlichten Strukturen konnten Mitglieder unterschiedlicher Entwicklungsteams zwischen den einzelnen Teilprojekten wechseln und produktivere Arbeitsergebnisse erzielen. Dank der projektübergreifenden Standardisierung war es nicht mehr notwendig, sich in komplizierte Prozesse einzuarbeiten, um das Projekt ausführen und testen zu können.

Die Entwicklung von Maven 1 wurde im Jahr 2003 begonnen und am 13. Juli 2004 als Version 1.0 veröffentlicht. Die Umsetzung wurde jedoch sehr schnell realisiert, sodass einige Eigenheiten nicht bedacht wurden. Beispielsweise gab es Probleme bei der Performance sowie einen Überschuss an Konfigurationsdateien und -angaben, die es zu beherrschen galt. 2014 wurde das End of Life (EoL) von Maven 1 verkündet. Die letzte veröffentlichte Version ist 1.1 vom 25. Juni 2007.

Im Jahr 2005 wurde parallel damit begonnen, Maven 2 zu entwickeln, welches mit Version 2.0 am 19. Oktober 2005 fertiggestellt wurde. Mit dem Major-Release 2 wurde Maven von Grund auf überarbeitet und bekannte Probleme aus der Vorgängerversion wurden behoben. Aus diesem Grund sind Maven 1 und Maven 2 untereinander inkompatibel. Am 18. Februar 2014 wurde das End of Life von Maven 2 kommuniziert. Die letzte veröffentlichte Version ist 2.2.1 aus November 2009.

Die Entwicklung von Maven 3 begann im Jahr 2008, bei der man sich insbesondere auf die Kompatibilität zwischen Maven 2 und 3 konzentrierte.

In der zweiten Hälfte des Jahres 2021 wurden die Arbeiten an Maven 4 begonnen. Eine wesentliche Verbesserung ist die stark optimierte Unterstützung von Multi-Modul-Projekten.

Wie funktioniert Maven?

Maven benötigt zur Ausführung eine Java virtuelle Maschine (JVM) und ist aufgrund dieses Umstandes plattformunabhängig. Aus diesem Grund kann es auf jedem Betriebssystem ausgeführt werden, für das eine Java VM verfügbar ist.

Der Kern von Maven ist mit wenigen Megabyte als Paket kompakt gehalten. Die interne Struktur ist modular aufgebaut. Sämtliche Funktionen werden über Erweiterungen, sogenannte Plugins, bei der erstmaligen Verwendung über ein öffentliches im Internet verfügbares Repository, Maven Central genannt, nachgeladen und in einem lokalen Repository abgelegt.

Maven ist deklarativ und basiert auf zwei wesentlichen Paradigmen. Zum einen auf „Don’t Repeat Yourself“ (DRY bzw. Wiederhole dich nicht selbst) bedeutet sinngemäß im Kontext von Maven, dass man nicht bei jedem Projekt dieselben Build-Schritte neu definiert muss. Und auf „Convention over Configuration“ (CoC bzw. Konvention vor Konfiguration). Dies bezieht sich auf die Konfigurationsdatei (POM), mit denen Maven-Projekte beschrieben werden. Durch festgelegte Konventionen haben möglichst viele Konfigurationseinträge gemeingültige Vorbelegungen (Default-Werte), die für die meisten Anwendungsfälle bereits die erwünschten Ergebnisse produzieren.

Maven folgt den beiden beschriebenen Paradigmen über den gesamten Zyklus der Softwareerstellung konsequent. Eine wichtige Voraussetzung für eine erfolgreiche Automatisierung der einzelnen Schritte des Softwareerstellungsprozesses sind strikte Vereinheitlichungen, wie sie durch die beiden Paradigmen DRY und CoC geschaffen werden.

Obwohl Maven bereits sehr viele Vorgaben liefert, können Projekte diese Vorgaben an ihre tatsächlichen Bedürfnisse anpassen. Sowohl für künftige neuere Versionen von Maven als auch bei der Anbindung von Drittanbieterprodukten ist es eine bewährte Praxis, möglichst nahe am Maven-Standard zu bleiben.

Wichtige Begriffe bei der Arbeit mit Maven

Im Zusammenhang mit Maven werden wichtige Begriffe verwendet, mit denen man vertraut sein sollte, um effektiv damit zu arbeiten:

• Artifacts (Artefakte) Diese werden in Maven sowohl Plugins als auch Abhängigkeiten zu externen Programmbibliotheken und die selbst erstellten binären Programmdateien des eigenen Softwareprojektes bezeichnet.
• Lifecycles (Lebenszyklen) Dies kann auch als Workflow oder Prozess verstanden werden. Maven kennt drei Lifecycles: „clean“, „site“ und „build“.
• Phases (Phasen) In diesen werden die einzelnen Schritte innerhalb eines „Lifecycles“ bezeichnet, die in festgelegter linearer Reihenfolge durchlaufen werden. Der Build-Lifecycle Default kennt 23 Schritte.
• Goals (Ziele) Sind einzelne Aktionen bzw. Funktionalitäten, die in einem Plugin bereitgestellt werden.
• Archetypes (Archetypen) In diesen können Gerüste für unterschiedlichste Arten von Softwareprojekten erstellt werden, deren Struktur dem Standard von Maven entspricht. Was auch als ein wesentliches Merkmal von Maven-Projekten ist. Die einheitliche Verzeichnisstruktur, auf die ich nachfolgend eingehen werde.

Verzeichnisstruktur

my-project/ – Wurzelverzeichnis

pom.xml – Projektbeschreibung (Build-Logik)

src/ – alle Eingabedateien

main/ – Eingabedateien für die Erstellung des eigentlichen Produkts

java/ – Java-Quelltext-Dateien

resources/ – Projektdateien, die kein Java-Quellcode sind, aber für die Übersetzung oder zur Laufzeit benötigt werden, z. B. Bilder, SQL, Java-Properties-Dateien etc.

test/ – Eingabedateien, die für automatisierte Testläufe benötigt werden

java/ – Testfälle, die als Java-Quellcode vorliegen, z. B. JUnit-Testfälle

resources/ – Zusätzliche Ressourcen für Testfälle

target/ – Alle durch Maven während des Build-Vorgangs erstellten Dateien

classes/ – kompilierte Java-Klassen

Die Konfigurationsdatei „pom.xml“

Die Konfigurationsdatei für Maven-Projekte hat die offizielle Bezeichnung „Project Object Model (POM)“und ist als pom.xml im Wurzelverzeichnis des Projektes abgelegt. Im Kontext des Build-Managements ist die pom.xml die Build-Logik, die von externen Werkzeugen wie dem Automatisierungsserver Jenkins aufgerufen wird. Über Jenkins habe ich bereits geschrieben.

Die zwingenden Basisangaben für ein Projekt innerhalb einer POM sind die sogenannten GAV-Parameter, zuzüglich des Packagetyps. GAV steht für (G) = GroupID, (A) = ArtifactId und (V) = Version. Die GAV-Koordinaten müssen für jedes Projekt eindeutig sein und dürfen nicht mehrfach Verwendung finden.

Abhängigkeiten bzw. (Dependency Management)

Einer der wichtigsten Faktoren für den Erfolg von Maven ist der einfache Umgang mit fremden Abhängigkeiten, sogenannten 3rd Party Libraries. Externe Abhängigkeiten werden in der pom.xml notiert und über ihre GAV-Koordinaten eindeutig und transitiv aufgelöst. Die definierten Abhängigkeiten werden nicht physisch in die Versionsverwaltung mit aufgenommen, sondern während des Buildvorgangs im Projekt-Ausgabeverzeichnis target bereitgestellt.

Bei der Verwendung eines Artefaktes prüft Maven, ob es bereits lokal im Repository vorhanden ist. Das lokale Repository ist ein verstecktes Verzeichnis mit der Bezeichnung .m2/repository und findet sich im home-Verzeichnis des am Betriebssystem angemeldeten Nutzers.

Wird von Maven das angeforderte Artefakt im lokalen Repository nicht gefunden, wird in einem öffentlichen Remote-Repository danach gesucht. Bei erfolgreicher Suche wird das Artefakt im lokalen Repository verfügbar gemacht. Das Wichtigste öffentlich frei verfügbare Repository für Java-Artefakte lautet „Maven Central“ und wird von dem Unternehmen Sonatype betrieben.

Es besteht die Möglichkeit, einen eigenen Repository-Server zu betreiben, um selbst erstellte Artefakte im Unternehmen bzw. im Intranet für andere Projekte bereitzustellen oder diese über das Internet zur Verfügung zu stellen.

Wichtige Implementierungen zum Hosten eigener Artefakte sind Sonatype Nexus OSS oder JFrog Artifactory, für die es sowohl freie Community Versionen als auch kommerzielle Enterprise-Varianten gibt. Diese Lösungen können neben den verschiedenen Java-Artefakten auch andere Formate wie beispielsweise Docker Images, RubyGems, .NET nuget oder NPM verwalten. Maven Central, das größte Open-Source-Repository, wird mit Nexus OSS betrieben.

Maven-Lebenszyklen (Lifecycles)

Wie bereits vorher erwähnt, kommen in einem Maven Workflow verschiedene Lebenszyklen zum Einsatz. Diese sind:

• clean (Zum Löschen von Ergebnissen vorheriger Builds, mit den Phasen pre-clean, clean, post-cl
• build (default) (Zum Erstellen eines Projekts im Rahmen der verschiedenen Phasen
• site (Zum Erstellen von Webseiten zur Projektdokumentation und Reports, mit den Phasen pre-site, site, post-site, site-deploy.

Maven geht dabei jeweils von einem Zyklus aus, der bei der Softwareerstellung im Allgemeinen durchlaufen wird. Es muss aber nicht jedes Softwareprojekt alle Phasen des im Folgenden verkürzt dargestellten Default-Zyklus verwenden. Die Standardfunktionalität kann durch die Einbindung von zusätzlichen Plug-ins an die entsprechende Phase erweitert werden.

• validate bzw. validieren (Es wird überprüft, ob die pom.xml und die Projektstrukturen vollständig, valide und gültig sind.
• compile bzw. kompilieren (In dieser Phase wird der Quellcode kompiliert.
• test bzw. testen (Hier wird der kompilierte Code durch das eingebundene Unit-Test-Framework (z. B. JUnit, TestNG) getestet. Maven berücksichtigt dabei in späteren Zyklen, dass Testklassen normalerweise nicht in der auszuliefernden Software vorhanden sind.
• package bzw. verpacken (Das Kompilat wird – ggf. mit anderen nicht kompilierbaren Dateien – zur Weitergabe verpackt. Häufig handelt es sich dabei um eine JAR-Datei.
• integration-test bzw. Integrationstests (Bereitstellen der programmatisch erstellten Integrationstests mittels Behavior Driven Development (z. B. Cucumber, jGiven).
• verify bzw. Gültigkeitsprüfung des Softwarepakets (Überprüfung der Artefakte, ob die festgelegten Spezifikationen erfüllt wurden, D.H. die bereitgestellten Integrationstests werden ausgeführt.
• install bzw. das Kopieren in die lokale Maven-Repository (Kopiert das Softwarepaket ins lokale Maven-Repository, um es dann in anderen lokalen Maven-Projekten verwenden zu können. Dies ist insbesondere für modulare Projekte von Bedeutung.
• deploy bzw. anwenden (Lädt das Softwarepaket in ein entferntes Maven-Repository hoch, wonach es auch anderen Entwicklern global zur Verfügung steht.

Fazit

Hierbei kann man sich relativ kurzfassen. Ein Software-Projekt sollte stehts mit einem vernünftigen Buildmanagement ausgestattet sein. Das Open-Source-Tool bietet sich dabei vor allem bei Java-Projekten an, zumal es selbst auf Java basiert. Es ist ebenso möglich, Maven durch selbst entwickelte Plugins zu erweitern. Aufgrund dieser Eigenschaft wird es auch als Plugin Execution Framework bezeichnet. Man kann damit die Kollaboration bei der Entwicklung durch Programmierer und Projektmanager mit verschiedensten Skill-Sets wesentlich erleichtern bzw. vereinfachen.

Der Beitrag Apache Maven – Projekte inklusive Abhängigkeiten mühelos verwalten erschien zuerst auf CEOsBay.