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.

„Ubuntu“ bedeutet auf Zulu etwa „Menschlichkeit“ und bezeichnet eine afrikanische Philosophie. Es schließt den Gemeinsinn, die gegenseitige Verantwortung und ein respektvolles Miteinander ein.

Die Entwickler verfolgen mit dem System das Ziel, ein einfach zu installierendes und leicht bedienbares Betriebssystem. Ein besonderes Augenmerk gilt auch auf die aufeinander optimierte Software. Downloaden kann man es sich über diesen Link.

Ich hielt meine erste physische Ubuntu CD im Jahr 2005, durch das ShipIt Programm in der Hand. Damals schickte man mir gleich ein ganzes Bündel der CD’s. Die habe ich in meinem näheren Umfeld und an ein paar Schulen verschenkt.

Die Nutzerzahl Stand heute ist auf etwa 40 Millionen Nutzer angestiegen. Neben Ubuntu selbst, dass von Version 11.04 bis 17.04 standardmäßig die von der Ubuntu-Entwicklergemeinschaft selbst entwickelte Desktop-Umgebung Unity einsetzte und seit Version 17.10 auf Gnome basiert, existieren verschiedene Abwandlungen. Ubuntu konnte seit dem Erscheinen der ersten Version im Oktober 2004 seine Bekanntheit stetig steigern. Es ist inzwischen eine der meistgenutzten GNU/Linux-Distributionen überhaupt. Dies verdankt es der relativ guten Benutzerfreundlichkeit.

Zu den offiziellen Unterprojekten gehören unter anderem Kubuntu mit KDE, Xubuntu mit Xfce, Ubuntu MATE, Ubuntu Budgie sowie Ubuntu Studio. Bei den verschiedenen Unterprojekten sind es meistens nicht nur die GUIs (Graphical User Interfaces bzw. Benutzeroberflächen), die angepasst sind, sondern auch die Softwarepakete, die mitgeliefert werden. Neue Ubuntu-Versionen erscheinen jedes halbe Jahr im April und Oktober.

Kurze Zeitreise

Der Unternehmer Mark Shuttleworth hat das Ubuntu – Projekt in den frühen 2000ern ins Leben gerufen, um ein Betriebssystem zu erschaffen, um es möglichst allen Menschen des Planeten zur Verfügung zu stellen. Wie in der Einleitung bereits erwähnt, stammt der Begriff Ubuntu aus den Sprachen der afrikanischen Völker Zulu und Xhosa und steht für „Menschlichkeit“ und „Gemeinsinn“, aber auch für den Glauben an ein universelles Band des Teilens, dass alles Menschliche verbindet.

Weitere Ziele des Projekts sind die Verbesserung der Globalisierung und der Barrierefreiheit, damit die angebotene Software für so viele Menschen wie möglich benutzbar wird. Derzeit kommen hier hauptsächlich die Übersetzungen und Hilfsmittel für Barrierefreiheit aus dem Gnome-Projekt zum Tragen.

Shuttleworth finanziert einen Großteil des Projektes selbst, wodurch dieser Distribution vergleichsweise mehr finanzielle Mittel zur Verfügung stehen als den meisten anderen Distributionen. Auch er selbst entwickelt mit. Neben ihm, arbeiten noch ungefähr 560 Mitarbeiter bei Canonical, davon ca. 400 Software-Engineers. Die meisten davon entstammen überwiegend den Debian- und Gnome-Online-Entwicklungsgemeinschaften. Finanziert wird die Entwicklung durch das von Shuttleworth gegründete Unternehmen Canonical, dass das System auch vermarktet.

Die erste Version von Ubuntu erschien im Oktober 2004 unter dem Namen Warty Warthog. Seitdem erscheint alle sechs Monate eine neue Fassung des Betriebssystems. Am 1. Juli 2005 wurde von Shuttleworth und Canonical die Ubuntu Foundation mit einem Startkapital von ca. 10 Millionen US-Dollar ins Leben gerufen. Diese kümmert sich primär um die Pflege der Ubuntu-Versionen nach deren Erscheinen und unterstützt die Weiterentwicklung. Auch ist es Ziel der Ubuntu Foundation Mitglieder der Kern-Community einzustellen, um das gemeinsame Ziel zu erreichen.

Eine weitere Finanzierungsquelle entstammt der seit der Fassung 12.10 eingebauten Suchfunktion, die anonymisiert Suchanfragen an den Onlinehändler Amazon verschickt. Diese zunächst standardmäßig aktivierte Funktion wurde mit der Version 16.04 wieder deaktiviert.

Unter der Haube von Ubuntu Linux

Wie bereits zu Beginn erwähnt, basiert Ubuntu auf Debian. Über die Debian Distribution werde ich ggf. noch einen gesonderten Beitrag schreiben. Wobei das Paketformat (.deb) und diverse Strukturen übernommen wurden. Zu Beginn eines Entwicklungszyklus wird ein Teil der Pakete mit denen aus Debian „unstable“ (Bedeutet, dass die Pakete nicht mehr auf ihre Richtigkeit überprüft oder anderweitig gepflegt werden) abgeglichen, insbesondere die des main-Bereichs werden vollständig und unabhängig gepflegt.

Hierdurch wird der Arbeitsaufwand für die Wartung der weniger wichtigen Programme reduziert. Alle Änderungen und Verbesserungen an Debian-Paketen, die in Ubuntu vorgenommen werden, stehen dem Debian-Projekt als Patches zur Verfügung. Theoretisch ist es aufgrund der strengen Paketdefinitionen auch möglich, Programmpakete aus Debian direkt zu benutzen, in der Praxis gibt es hierbei jedoch insbesondere bei systemnahen Funktionen aufgrund diverser Detailunterschiede oftmals Probleme.

Das Ubuntu Linux Software Center

Ab Version 11.10 ist das Software Center in Ubuntu verfügbar, welches mit dem Apple App Store oder dem Google Play Store verglichen werden kann. Das Programm dient zur einfachen Installation und Verwaltung bzw. Deinstallation von Software. Die Entwickler von Ubuntu bezwecken hiermit, die verfügbaren Applikationen für das Betriebssystem langfristig zu steigern.

Nach der Standardinstallation von Ubuntu ist ein Administrator-Benutzerkonto „Root-Account“ (Account mit erweiterten Systemprivilegien) zwar vorhanden, ist aber – wie bei macOS – durch ein ungültiges Kennwort deaktiviert. Es ist daher in der Standardkonfiguration nicht möglich, sich direkt als „root“ anzumelden, wodurch das ungewollte Starten und Modifizieren von Programmen mit Administratorrechten und eine möglicherweise dadurch verursachte nachteilige Änderung am System verhindert wird.

Mithilfe des Befehls „sudo“ kann das mit eingeschränkten Rechten ausgestattete Benutzerkonto allerdings vorübergehend vollständige Systemprivilegien erhalten, was etwa zur Installation und Modifikation mancher Programme, sowie für einige kritische Befehle notwendig ist.

Ubuntu war neben SUSE Linux eines der Distributionen, die mich nach Jahren zu Linux zurückgebracht hat. Doch wie vorher erwähnt, ist der mangelnde Datenschutz auf jeden Fall ein Manko, welches nicht selten bei dieser Distribution auftrat.

Diesen kritisierte beispielsweise die Electronic Frontier Foundation wegen der Einbindung des Onlineshops von Amazon. Der Vorwurf, Adware zu beinhalten, kam auf, weil die vorher nur auf installierte Programme und lokale Dateien gerichtete Suchfunktion des Desktops auf den Shop von Amazon erweitert wurde, um passende Angebote auszugeben.

Das abzuschalten wurde zwar kurz darauf ermöglicht, doch Richard Stallman bezeichnete Ubuntu gerechtfertigter weise als Spyware. Im Oktober 2013 bekam Shuttleworth für die Funktion einen Big Brother Award in Österreich. Grüße nach Österreich 😉

Mit Ubuntu 16.04 wurde das Dateisystem ZFS (ZFS ist ein Dateisystem mit Volume-Management-Funktionen) in die Distribution integriert. Die für ZFS verwendete Lizenz Common Development and Distribution License (CDDL) wird von der Free Software Foundation allerdings als nicht mit der GPL vereinbar bezeichnet. Die Organisation Software Freedom Conservancy spricht in diesem Zusammenhang von einer Lizenzverletzung.

Fazit

Ubuntu ist eine ausgezeichnete Distribution, um sich mit Linux als Betriebssystem und mit Open Source vertraut zu machen, wenn man noch nicht viele Berührungspunkte mit Linux hatte. Darüber hinaus gibt es viele verschiedene Unterprojekte, wie Kubuntu, Mate usw. die eine Aufwertung alter Computersysteme ermöglichen. Nichtsdestotrotz gefällt mir persönlich der negative Beigeschmack bzgl. des vernachlässigten Datenschutzes nicht. Als Unternehmer ist es mir klar, dass man für die Entwicklung von Software Geld benötigt. Doch die Zusammenarbeit mit Amazon, in der Form wie es geschehen ist, erscheint mir persönlich nicht richtig.

Der Beitrag Ubuntu Linux – Das benutzerfreundliche und stabile Betriebssystem erschien zuerst auf CEOsBay.

Minimierung (Minification / Minify)

Unter Minifizierung versteht man das Entfernen aller überflüssigen Zeichen aus dem Quellcode von interpretierten Programmiersprachen oder Markup-Sprachen, ohne dessen Funktionalität zu verändern. Dazu in einem separaten Beitrag mehr.

CSS (Cascading Style Sheets)

Eine Programmiersprache, die es ermöglicht, das Design von elektronischen Dokumenten zu bestimmen. Auch hier bei einem separaten Beitrag mehr.

Sass (Syntactically Awesome Stylesheets)

CSS mit Superkräften bzw. auf Steroiden. Dies werde ich auch in einem separaten Beitrag ausführlich thematisieren.

npm

Der Node Package Manager ist ein Paketmanager für die JavaScript-Programmiersprache, der von npm, Inc. gepflegt wird. npm ist der Standard-Paketmanager für die JavaScript-Laufzeitumgebung Node. Es vereinfacht das Installieren von Node-„Paketen“. Ein Paket, auch Modul genannt, ist lediglich eine Code-Bibliothek, die Node um nützliche Funktionen erweitert. Das Modul „request“ zum Beispiel vereinfacht https-Anfragen, so dass man problemlos Webressourcen von anderen Websites abrufen kann. npm wird bei der Installation von Node mitinstalliert. Obwohl es auf der Node-Website ein MacOS-Installationsprogramm gibt, wird die Verwendung von Homebrew zur Installation und Aktualisierung von Node empfohlen. Über und wie man Homebrew installiert bzw. verwendet, kann in einem anderen Beitrag gelesen werden, den ich geschrieben habe.

Grundsätzlich sollte man mit dem Mac-Terminal vertraut sein, da es zum Installieren und Testen von Node und npm verwenden werden muss. Die Terminal-Anwendung befindet sich im Dienstprogramme Ordner unter den Programmen. Ansonsten kann man auch einfach mit der Tastenkombination Command + Leertaste im Spotlight nach dem Terminus Terminal suchen. Durch die Verwendung von Homebrew können etwaige Sicherheitsprobleme vermieden werden, die mit der Verwendung des sudo-Befehls zur Installation von Software wie Node und Node-Modulen einhergehen.

Installation

Die Installation von Node.js® und npm ist mit Homebrew relativ einfach. Homebrew übernimmt das Herunterladen, Entpacken (Eine komprimierte bzw. archivierte Datei extrahieren) und Installieren von Node.js® und npm auf dem System. Der Installationsprozess dauert lediglich ein paar Minuten.

Ist das Terminal geöffnet, geht es folgendermaßen weiter:

brew update

brew update aktualisiert die Repository

brew install node

Hiermit lässt sich Node.js® installieren

node -v

Mit diesem Befehl lässt sich überprüfen, ob und in welcher Version Node installiert ist.

npm -v

Und hiermit, ob und in welcher Version npm installiert ist.

Damit sind Node.JS® und npm erfolgreich installiert!

Der Beitrag Node.js® mit npm auf MacOS erschien zuerst auf CEOsBay.