Was ist ein Generic Code Editor (GCE)?

Ein Generic Code Editor ist ein universeller Code-Editor, der eine Vielzahl von Programmiersprachen unterstützt, ohne sich auf eine bestimmte Umgebung oder Sprache zu spezialisieren. Seine Hauptmerkmale sind:

• Syntax-Highlighting für verschiedene Sprachen
• Autovervollständigung für besseren Workflow
• Erweiterbarkeit durch Plugins
• Plattformunabhängigkeit für eine flexible Nutzung
• Leichtgewichtige Performance, ohne eine komplexe Projektverwaltung

Ein Generic Code Editor ist kein vollständiges Entwicklungswerkzeug, sondern ein flexibler Editor zur Bearbeitung von Code in mehreren Sprachen. Er eignet sich besonders für schnelle Änderungen an Code-Dateien, Skripte oder für Entwickler, die in mehreren Programmiersprachen arbeiten.

Vorteile eines Generic Code Editors

1. Flexibilität – Unterstützt verschiedene Sprachen ohne spezielle Anpassungen.
2. Leichtgewichtigkeit – Schneller Start und geringe Systemanforderungen.
3. Erweiterbarkeit – Plugins und Erweiterungen können individuell hinzugefügt werden.
4. Plattformunabhängig – Funktioniert auf Windows, macOS und Linux.
5. Kein Overhead – Keine komplexen Projektkonfigurationen notwendig.

Bekannte Generic Code Editors

• Visual Studio Code (VS Code) – Sehr populär mit einer großen Erweiterungsbibliothek. (Siehe auch meinen Beitrag „Visual Studio Code – Das leichte Schwergewicht„)
• Atom – Open-Source-Editor von GitHub (War eines meiner Lieblingseditoren, wird allerdings nicht mehr aktiv weiterentwickelt).
• Sublime Text – Leichtgewichtig, schnell und mit guter Plugin-Unterstützung. (Aktuell eines meiner Lieblingseditoren auf macOS)
• Notepad++ – Einfacher, schneller Editor mit grundlegenden Funktionen. (Aktuell eines meiner Lieblingseditoren auf Windows)
• Vim/NeoVim – Terminal-basierter Editor mit hoher Anpassbarkeit. (Aktuell eines meiner Lieblingseditoren auf Linux-Systemen wie KALI, Debian und Ubuntu)

Vergleich: GCE vs. IDE

Was zählt nicht als Generic Code Editor?

Einige Entwicklungsumgebungen unterstützen zwar mehrere Sprachen, sind aber keine GCEs, weil sie mehr als nur reine Code-Bearbeitung bieten. Dazu gehören:

1. IntelliJ IDEA – Die Power-IDE für Java & Co.

IntelliJ IDEA von JetBrains ist primär für Java und Kotlin entwickelt, unterstützt jedoch durch Plugins viele weitere Sprachen. Es bietet:

• Automatisches Refactoring für sauberen Code
• Integrierten Debugger zur Fehleranalyse
• Projektmanagement mit Build-Tools (Maven, Gradle)
• Intelligente Code-Analyse zur Fehlererkennung
• Version Control (Git, SVN) direkt integriert

2. Visual Studio – Microsofts leistungsstarke Entwicklungsumgebung

Visual Studio ist besonders für .NET- und C#-Entwicklung optimiert, unterstützt aber auch C++, Python und andere Sprachen. Seine Merkmale umfassen:

• Integrierte Compiler & Debugging-Tools
• Automatische Code-Generierung & AI-gestützte Features
• GUI-Designer für App-Entwicklung
• Umfassendes Projektmanagement mit Solution Explorer

Was ist mit Visual Studio Code?

Eine interessante Ausnahme ist Visual Studio Code (VS Code). Es ist leichter als Visual Studio, unterstützt viele Sprachen und wird oft als Generic Code Editor genutzt. Durch Erweiterungen kann es jedoch zu einer fast vollständigen IDE ausgebaut werden.

Wann solltest du einen GCE statt einer IDE nutzen?

Ein Generic Code Editor eignet sich besonders, wenn du:

• Mit vielen verschiedenen Programmiersprachen arbeitest und schnelle Bearbeitung benötigst.
• Kein vollständiges Projektmanagement brauchst, sondern nur einzelne Dateien editieren möchtest.
• Leichtgewichtige Tools bevorzugst, die nicht viele Ressourcen verbrauchen.
• Oft in Terminal- oder Cloud-Umgebungen arbeitest und keinen GUI-basierten Editor benötigst.

Fazit: GCE oder IDE?

Ein echter Generic Code Editor ist leichtgewichtig, universell und nicht an eine bestimmte Sprache oder Umgebung gebunden. IntelliJ IDEA und Visual Studio hingegen sind vollständige IDEs mit Debugging- und Projektmanagement-Funktionen, die über die Eigenschaften eines GCE hinausgehen.

Wenn du also nach einem leistungsstarken Entwicklungswerkzeug mit Debugging und Projektmanagement suchst, sind IntelliJ IDEA oder Visual Studio großartige Optionen. Falls du hingegen einen flexiblen, leichtgewichtigen Editor für mehrere Sprachen möchtest, sind VS Code, Sublime Text oder Vim die bessere Wahl.

Der Beitrag Generic Code Editors – Flexibel, Leicht & Vielseitig erschien zuerst auf CEOsBay.

Geschichte von Xcode

Apple präsentierte es erstmals im Jahr 2003. Es diente als Nachfolger der NeXTSTEP-Entwicklungstools, die Apple durch den Kauf von NeXT im Jahr 1997 erwarb. Es hat seinen Ursprung im Bestreben von Apple, den Entwicklern eine effiziente und intuitive Umgebung zu bieten, in der sie qualitativ hochwertige Apps für die wachsende Palette von Apple-Produkten erstellen können.

Aufsetzen von Xcode

Das Installieren und Einrichten gestaltet sich denkbar einfach:

1. Download und Installation: Xcode steht im Mac App Store zur Verfügung. Ein einfacher Suchbegriff danach führt direkt zum Download-Button.
2. Erstes Öffnen: Nach der Installation das Programm starten. Hier kann man ein neues Projekt erstellen oder ein bestehendes öffnen.
3. Wichtige Einstellungen: In den Einstellungen lassen sich viele individuelle Anpassungen vornehmen, etwa die Auswahl eines Themes oder die Konfiguration der Texteditor-Eigenschaften.

Best Practices bei der Nutzung von Xcode

Um das Beste herauszuholen, empfehlen sich folgende Praktiken:

• Regelmäßige Aktualisierungen: Apple veröffentlicht regelmäßig Updates. Diese bringen oft neue Funktionen, Bugfixes und Performance-Verbesserungen mit sich. (An dieser Stelle macht es Sinn, meinen Beitrag über das Pestizid Paradoxon zu erwähnen)
• Nutzung der Interface Builder: Dieses visuelle Tool ermöglicht das einfache Design von Benutzeroberflächen per Drag-and-Drop.
• Effektive Nutzung von Simulatoren: Es bietet Simulatoren für alle Apple-Geräte. Sie sind unerlässlich für das Testen von Apps unter verschiedenen Bedingungen und Bildschirmgrößen.
• Verwendung von Profiling-Tools: Instruments, ein in Xcode integriertes Tool, hilft dabei, Engpässe in der App-Performance zu identifizieren und zu beheben.

ARKit – Eine Revolution in der Augmented Reality

ARKit, von Apple entwickelt und in iOS eingeführt, markiert einen Wendepunkt in der Welt der Augmented Reality (AR). Dieses Framework ermöglicht Entwicklern das Erstellen von beeindruckenden AR-Erlebnissen für iPhone und iPad. ARKit nutzt dabei hochentwickelte Algorithmen, um die Kamera-Bildinformationen und Bewegungssensordaten zu kombinieren und so die Position des Geräts in der realen Welt zu verfolgen. Es unterstützt auch die Erkennung von horizontalen und vertikalen Flächen, Gesichtserkennung und 3D-Objekterkennung. Mit jedem Update erweitert Apple die Fähigkeiten von ARKit, wodurch Entwickler noch tiefere und immersivere AR-Erfahrungen schaffen können. Egal, ob es um virtuelle Möbelplatzierung, interaktive Spiele oder Lernanwendungen geht, ARKit treibt die Möglichkeiten der Augmented Reality auf Apple-Geräten voran.

Fazit

Xcode steht im Zentrum der Apple-Entwicklungswelt. Von seinen Anfängen im Jahr 2003 bis heute hat es sich stetig weiterentwickelt und bietet Entwicklern eine leistungsstarke Umgebung, um erstklassige Apps zu erstellen. Durch die Beachtung von Best Practices und eine effektive Nutzung der in Xcode integrierten Tools können Entwickler ihre Produktivität steigern und qualitativ hochwertige Produkte liefern. In den kommenden Wochen habe ich auf jeden Fall noch vor, die ein oder andere kleine App vorzustellen. In diesem Kontext bietet es sich auch an, den Workflow anzuschauen, wie man effektiv Apps in und mit Xcode erstellen kann.

Der Beitrag Xcode – Wo Ideen zu Apple-Apps werden erschien zuerst auf CEOsBay.

Was ist JAXB-2?

JAXB-2 ist ein leistungsfähiges Tool, das Java-Entwicklern dabei hilft, XML-Schemata in Java-Klassen umzuwandeln und umgekehrt. Es basiert auf der JAXB-API und man verwendet es hauptsächlich für das Parsen, Validieren, Marshallen und Unmarshallen von XML-Dokumenten.

Kurze Zeitreise

JAXB, einschließlich seiner Version 2, ist ein Teil der Java-Plattform, Standard Edition (Java SE). Es entstand aus dem Bedürfnis, eine standardisierte Methode für das Binden von XML-Schemata an Java-Objekte bereitzustellen. Dies ist eine häufige Anforderung für viele Java-Anwendungen, da XML eine weit verbreitete Technologie für den Datenaustausch zwischen Systemen und Anwendungen ist.

Im Detail ist JAXB ein vom Java Community Process (JCP) spezifiziertes API und wurde ursprünglich als Teil der Java Web Services Development Pack (JWSDP) eingeführt. JAXB 2.0, veröffentlicht im Jahr 2006, stellte eine wichtige Weiterentwicklung dar, die den Benutzern zusätzliche Flexibilität und Leistung bot. Es erlaubte unter anderem die Nutzung von generischen Sammlungstypen, erweiterte Anpassungen und verbesserte Validierungsmöglichkeiten.

Insgesamt ist JAXB-2 aus der Notwendigkeit entstanden, eine effiziente und standardisierte Methode für die Interaktion zwischen Java und XML bereitzustellen, die weitgehend unabhängig von den spezifischen Anforderungen einer Anwendung ist.

Vorteile als Maven Plugin

Das JAXB-2 Maven Plugin bietet eine nahtlose Integration mit Maven, wodurch Entwickler die Möglichkeit erhalten, ihre XML-zu-Java Bindungen direkt in ihre Build-Prozesse zu integrieren. Darüber hinaus unterstützt das Plugin die neuesten JAXB-Versionen und bietet mehrere Erweiterungen, um eine erweiterte Kontrolle über die Generierung von Java-Klassen zu ermöglichen.

Einrichten des Maven Plugins

Um das JAXB-2 Maven Plugin zu verwenden, muss man es zuerst in einer pom.xml-Datei konfigurieren. Hier ist ein Beispiel für eine Grundkonfiguration:

<project>
...
    <build>
        <plugins>
            <plugin>
                <groupId>org.ceosbay.yoyo</groupId>
                <artifactId>jaxb2-maven-plugin</artifactId>
                <version>2.5.0</version>
                <executions>
                    <execution>
                        <id>xjc</id>
                        <goals>
                            <goal>xjc</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <schemaDirectory>${project.basedir}/src/main/resources/schema</schemaDirectory>
                    <outputDirectory>${project.basedir}/src/main/java</outputDirectory>
                    <clearOutputDir>false</clearOutputDir>
                </configuration>
            </plugin>
        </plugins>
    </build>
...
</project>

Das Maven Plugin in Aktion

Nachdem man das JAXB-2 Maven Plugin konfiguriert hat, wird Maven automatisch die Java-Klassen aus den in <schemaDirectory> angegebenen XML-Schemas generieren, wann immer man das Projekt baut. Diese Klassen werden im durch <outputDirectory> definierten Verzeichnis gespeichert.

Fazit

Das JAXB-2 Maven Plugin ist ein effektives Werkzeug zur Integration von XML-Bindungen in Java-Projekte. Mit seiner Hilfe kann man Projekte effizienter gestalten und den Build-Prozess weiter automatisieren.

Der Beitrag JAXB-2 (Maven Plugin) – XML in Möglichkeiten verwandeln erschien zuerst auf CEOsBay.

Funktionen

Lombok bietet eine Vielzahl von Funktionen, die Entwicklern helfen, effizienten Code zu schreiben. Hier sind einige der wichtigsten Funktionen:

Getter und Setter:

Lombok ermöglicht es Entwicklern, Getter und Setter-Methoden für Klassenvariablen automatisch zu generieren. Dies ist besonders nützlich, wenn man viele Klassenvariablen hat und nicht jedes Mal manuell Getter und Setter schreiben möchte.

Konstruktoren:

Entwickler können Konstruktoren für ihre Klassen automatisch generieren lassen. Dies ist besonders nützlich, wenn man eine Klasse mit vielen Variablen hat und einen Konstruktor erstellen möchte, der diese Variablen automatisch initialisiert.

Builder:

Mit dem Builder können Entwickler Builder-Klassen automatisch generieren lassen, die es einfach machen, komplexe Objekte zu erstellen. Der Builder generiert eine Methode für jede Klassenvariable, mit der man den Wert der Variable setzen kann. Sobald alle Variablen gesetzt sind, erfolgt die Rückgabe des Objekts.

ToString:

Entwickler können die toString-Methode automatisch generieren lassen. Dies macht es einfach, die Inhalte eines Objekts zu debuggen oder zu protokollieren.

Equals und HashCode:

Entwickler können equals- und hashCode-Methoden automatisch generieren lassen. Dies ist besonders nützlich, wenn man eine Klasse hat, die Verwendung in einer Hash-Map hat.

Log:

Es bietet eine Annotation, mit der Entwickler eine Logger-Variable automatisch generieren können. Dies macht es einfach, Protokolle in der Anwendung zu erstellen.

Installation

Um Lombok in einem Projekt zu verwenden, muss man es installieren. Es gibt mehrere Möglichkeiten, Lombok zu installieren, doch die einfachste Methode besteht darin, die Lombok-JAR-Datei in das Projektverzeichnis zu kopieren und diese dann zu der IDE-Konfiguration hinzuzufügen. Als IDE’s sind beispielsweise IntelliJ oder Eclipse zu erwähnen.

Wenn man Maven verwendet, kann man Lombok einfach zu der POM-File hinzufügen:

<dependency>

   <groupId>org.projectlombok</groupId>

   <artifactId>lombok</artifactId>

   <version>X.XX.XX</version>

   <scope>provided</scope>

</dependency>

Sobald es installiert ist, kann man die verschiedenen Annotationen verwenden, um den Code zu verbessern.

Der Beitrag Lombok – Entwicklerproduktivität steigern und Boilerplate-Code eliminieren für sauberen, effizienten Java-Code 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.

Kurze Zeitreise

Eclipse ist im Grunde genommen der Nachfolger von IBM Visual Age for Java 4.0. Der Quellcode dafür wurde im Jahr 2001 von IBM freigegeben. Im Jahr 2004 beschloss das von IBM geführte Eclipse-Konsortium die Ausgründung der rechtlich eigenständigen Eclipse Foundation, die seitdem für die Entwicklung von Eclipse verantwortlich ist. Es unterstützt die Java-Version 5 ab Version 3.1 und Java 6 ab Version 3.2. Ab dem Jahr 2006 wurden die Veröffentlichungstermine neuer Versionen der wichtigsten Eclipse-Komponenten harmonisiert, um Versionskonflikte zu vermeiden und Eclipse-Anwendern die Nutzung zu erleichtern. Man hat den Veröffentlichungszyklus ab der Version 2018-09 auf Quartalsaktualisierungen verkürzt, da ab Java 9 nicht mehr alle 3 Jahre, sondern alle 6 Monate eine neue Java Version erscheint. Es folgt nun einem Rolling Release Modell.

Rolling Release

(„rollen“ und „veröffentlichen“. Sinngemäß handelt es sich dabei um die kontinuierliche Aktualisierung der Software und ist ein Begriff aus der Softwareentwicklung. Bei einem Betriebssystem, dass das Rolling-Release-Prinzip anwendet, gibt es keine Betriebssystem-Versionen, bei denen bei einem Versions-Upgrade eine große Menge an Software auf einmal aktualisiert wird. Die einzelnen Software-Pakete werden vielmehr immerfort aktualisiert. Dies schließt sogenannte Releases, also Veröffentlichungen des Betriebssystems, aber nicht aus. Im Gegensatz zu einem Betriebssystem ohne Rolling Releases sind die Veröffentlichungen jedoch keine Versionen, sondern sogenannte Snapshots. Dies bedeutet, eine Kopie aller im Moment im Repository liegenden Software-Versionen. Diese Snapshots dienen meistens auch als Installations-Medien.

Die Projektnamen waren bisher nach den Jupitermonden (Callisto, Europa und Ganymede), den Raumsonden Galileo und Helios, die Version 3.7 nach der für Eclipse typischen Farbe Indigo benannt. Die Anfangsbuchstaben der Projektnamen werden ab Version 3.5 in alphabetischer Reihenfolge vergeben. Die Version 3.8 erschien gleichzeitig mit der Version 4.2. Um mit dem schnelleren Release-Zyklus von Java mitzuhalten, hat man 2018 von einem jährlichen Release auf vier Releases pro Jahr umgestellt. Damit hat man auch das Namensschema der Release-Versionen auf „{Jahreszahl}-{Monat}“ vereinfacht, also beispielsweise „2018-09“. Die einzelnen Versionen werden jeweils als Grundversion oder als Zusammenstellung aus verschiedenen Programmpaketen veröffentlicht. Einzelne Programmpakete kann man jedoch auch später noch nachinstallieren. Die Benutzeroberfläche von Eclipse ist standardmäßig englischsprachig. Es gibt jedoch zu jeder Version Babel-Language-Packs, die man sich in den entsprechenden Sprachen als Plugin installieren kann.

Darauf gehe ich so explizit ein, da ich mich in den letzten Tagen mit Kollegen über Eclipse ausgetauscht und in einem Quellcode verweise auf „Jupiter“ entdeckt habe. In der jüngsten Vergangenheit habe ich mich mit Jupyter beschäftigt. Daher auch hier ein Verweis auf den Beitrag damit es zu keiner Verwechslung der Themen kommt. Beides von Grund auf verschiedene Themen bzw. Dinge 😉

Architektur

Bis einschließlich zur Version 2.1 ist Eclipse als erweiterbare IDE konzipiert gewesen. Ab Version 3.0 ist es selbst nur der Kern, der die einzelnen Plug-ins lädt, die dann die eigentliche Funktionalität zur Verfügung stellt. Diese Funktionalität basiert, wie bereits erwähnt, auf Equinox. Sowohl Eclipse als auch die Plugins sind vollständig in Java implementiert. Zur Erstellung der GUI (grafischen Benutzeroberfläche) wurde SWT verwendet. Zur Darstellung der GUI-Komponenten basiert SWT ähnlich wie AWT auf den nativen GUI-Komponenten des jeweiligen Betriebssystems. Eclipse steht für 14 verschiedene Systeme und Architekturen zur Verfügung und gilt somit als plattformunabhängig. Die Plugins lassen sich direkt von einem Update-Server, über den „Market Place“, oder durch Entpacken einer Installationsdatei installieren.

Das frei verfügbare Eclipse SDK umfasst die Eclipse-Plattform, Werkzeuge zur Java-Entwicklung (Java Development Tools, JDT) und die Umgebung zur Entwicklung von Eclipse-Plugins (Plugin Development Environment, PDE).

Rich Client Platform

Eclipse bietet eine Rich Client Platform, welche es Anwendungsentwicklern ermöglicht, basierend auf dem Eclipse-Framework, von der Eclipse-IDE unabhängige Anwendungen zu schreiben. Die folgenden Komponenten (Plugins) werden typischerweise mindestens für eine Eclipse-Rich-Client-Platform-Anwendung verwendet:

• Eclipse Core Platform – steuert den Lebenszyklus einer Eclipse-Anwendung
• Eclipse Platform UI – stellt die Workbench mit den Konzepten Sichten, Editoren, Perspektiven, Menüs und Toolbars zur Verfügung
• Standard Widget Toolkit (SWT)
• JFace

Weitere Eclipse-Komponenten, wie das Hilfesystem oder das automatische Aktualisierungssystem, kann man ebenfalls einsetzen. In der Regel nutzt man das Eclipse-OSGi-Framework Equinox zum Kombinieren (bundling) der Komponenten.

Das UI (User Interface)

Eclipse ist in Komponenten (parts) gegliedert, die in Sichten (views) und Editoren (editors) gegliedert sind. Wobei die Unterscheidung in view und editor sich an der Nutzung orientiert und nicht technischer Natur ist. Diese Fenster kann man durch Drag and Drop beliebig anordnen oder minimieren.

Sichten

Mit Hilfe der views kann man Daten direkt bearbeitet und darunterliegende Datenstrukturen verändern.

Beispiele für views sind die auch aus den meisten anderen Editoren bekannte Navigator-View, die im Projektverzeichnis enthaltene Dokumente anzeigt, der Klassenexplorer, der baumartig strukturiert Symbole für die Klassen, Funktionen, Variablen und Importe eines geöffneten Quelltextes anzeigt oder das Suchfenster, dass die Ergebnisse einer Suche auflisten kann.

Editoren

Editoren sind Komponenten, die nur das jeweils geöffnete Datenelement bearbeiten und in denen der Nutzer explizit speichern muss, um Daten zu verändern. Beispiele sind Fenster, die meist den Quelltext mit Syntaxhervorhebung anzeigen, wobei es für viele Programmiersprachen einen eigenen Editor gibt. Beispielsweise für Java, C, PHP, Python, HTML, aber auch einen einfachen Texteditor. Genauso gibt es auch visuelle Editoren (beispielsweise UML-Editoren, GUI-Builder) oder solche, die Baumstrukturen anzeigen (etwa der XML-Editor). Editoren nehmen normalerweise den meisten Raum des Programmfensters in Anspruch. Mehrere geöffnete Quelltexte kann man als Reiter öffnen, die man dann über Tabs am oberen Rand in den Vordergrund bringen kann. Außerdem kann man Tabs fixieren, damit man beispielsweise den zugehörigen Quelltext nicht versehentlich schließt. Auch kann man die Editoren weitestgehend frei per Drag and Drop anordnen. Davon abgesehen ist es möglich, eine Datei in mehreren Editoren gleichzeitig zu öffnen.

Perspektiven

Perspektiven sind vollständige Anordnungen von parts. Ein editor bleibt beim Perspektivwechsel erhalten. Perspektiven sind weitestgehend frei konfigurierbar und man kann benutzerdefinierte Konstellationen speichern sowie laden. Meistens stellen Plugins, die man nachinstalliert, vorkonfigurierte Perspektiven zur Verfügung, diese passt man dann meisten den eigenen Wünschen und Vorlieben an.

Plugins und Erweiterungen

Es gibt zahlreiche Erweiterungen für Eclipse. Teils proprietär, teils frei verwendbar bzw. Open Source. Primär verwendet man es als Java IDE. Dabei kommen vor allem die in den Java Development Tools zusammengefassten Plugins zum Einsatz. Es existieren aber etliche Plugins für andere Sprachen, die ich bereits unter Editoren erwähnt habe. Hinzu kommt noch die Entwicklung von OSGi-Bundles. Dazu zählt vor allem das CDT-Projekt, welches C und C++ unterstützt und unter Anderem die GNU Compiler Collection sowie die LLVM (-Clang und -GCC) abdeckt. Darüber hinaus gibt es auch Plugins für Perl, PHP, ColdFusion, Ruby, Python, C#, Fortran, Ada2005, Scala usw. Diese kann man über ein Menü in Eclipse einbinden. Neben Plugins für konkrete Programmiersprachen gibt es auch solche, die allgemeine Entwicklungsprozesse unterstützen, wie beispielsweise Mylyn für „aufgabenorientierte Entwicklung“ oder Saros für Verteilte Paarprogrammierung auch Distributed Pair Programming, DPP oder Pair Programming, PP genannt. Oft sind diese Ergänzungen – anders als das Kernprogramm – ausschließlich in der englischen Sprache erhältlich.

Neben den Java Development Tools gibt es viele weitere Projekte, die man ebenfalls auf der Eclipse-Website koordiniert. Ein solches Projekt ist das Eclipse Tools Project, dass verschiedene Hilfsmittel entwickelt, die Entwickler erweitern können. Weitere Projekte sind das Eclipse Modeling Framework (EMF), das Graphical Editing Framework (GEF) und die eingestellte Eclipse Riena Platform (Riena). Mit EMF lässt sich ein Datenmodell erstellen, das zum Beispiel auf UML basieren kann. GEF ist ein Projekt, dass es Entwicklern erlaubt, mit Hilfe eines existierenden Datenmodells schnell einen grafischen Editor zu erstellen. Riena unterstützt Entwickler bei der Ausstattung einer Anwendung mit einem benutzerfreundlichen Interaktionskonzept und ansprechenden Oberflächenelementen.

Basierend auf diesen Erweiterungen und dem modularen Aufbau von Eclipse selbst, lassen sich für Projekte spezifische Eclipse-Bundles erstellen. Diese enthalten alle für ein bestimmtes Projekt notwendigen Teile und Erweiterungen von Eclipse, ohne mit unnötigen Teilen Hauptspeicher und Rechenleistung zu verbrauchen.

Inzwischen gibt es auch Open Source-Erweiterungen, die eine automatisierte Bereitstellung und Konfiguration erheblich erleichtern. Dazu zählen oasp4j-ide, Oomph und Yatta Profiles, von denen ich einige in zukünftigen Beiträgen thematisiere.

Fazit

Durch den quelloffenen Ansatz und der kostenfreien Nutzungsmöglichkeit ist Eclipse neben IntelliJ eines der beliebteren IDEs. Man kann durch Plugins und Erweiterungen viele Programmiersprachen bedienen. Der Programmkern von Eclipse stellt in dem Zusammenhang die einzige versionsübergreifende Konstante dar. Jede Aktualisierung führt Neuerungen in den Kern ein und die integrierten Plugins bzw. Erweiterungen erfordern dadurch meist eine Anpassung an die neue Version.

Die grafische Oberfläche von Eclipse ist auf eine effiziente Arbeitsweise ausgerichtet. Der konzeptionelle Aufbau durch Views, Editoren und Perspektiven sorgt für eine anpassbare Optik und eine bequeme Arbeitsweise mit und in der IDE. Man kann sowohl die Funktionalitäten als auch die GUI von Eclipse durch die manuelle oder automatische Installation von Plugins bzw. Erweiterungen anpassen. Entsprechende Möglichkeiten finden sich in dem standardmäßig integrierten Market Place von Eclipse.

Der Beitrag Eclipse – Die flexible Entwicklungsumgebung erschien zuerst auf CEOsBay.

JUnit wird zur Kompilierzeit als JAR gelinkt. Bei einem JAR handelt es sich um ein Java Archiv (umgangssprachlich wegen der Dateiendung auch JAR-Datei genannt) dient der Gliederung, Verteilung und Bereitstellung von Klassenbibliotheken und ausführbaren Programmen, die in der Programmiersprache Java erstellt wurden. Technisch ist es eine komprimierte Datei im ZIP-Format. Das Archiv enthält kompilierte Java-Klassen (Bytecode) und ggf. weitere Ressourcen. In der Regel umfasst es auch eine oder mehrere Dateien mit Metadaten. Diese haben fest vorgegebene Namen und Strukturen und liegen im Verzeichnis META-INF. Wie es genau funktioniert, schreibe ich in einem zukünftigen Beitrag. Auf jeden Fall kann man sich die Kurzbezeichnung des Archivs als Wortspiel mit dem englischen Wort jar (deutsch: „Gefäß“) ganz gut merken.

Die neueste Version des Frameworks, JUnit 5, befindet sich im Paket org.junit.jupiter. Die Vorgängerversionen JUnit 4 und JUnit 3 waren unter den Paketen org.junit bzw. junit.framework zu finden.

Eine im Jahr 2013 durchgeführte Umfrage unter 10.000 auf GitHub gehosteten Java-Projekten ergab, dass JUnit (gleichauf mit slf4j-api) die am häufigsten eingebundene externe Bibliothek ist. Jede Bibliothek wurde von 30,7 % der Projekte verwendet.

Wie funktioniert JUnit?

Ein JUnit-Test kennt nur zwei Ergebnisse: Entweder der Test gelingt (dann ist dieser „grün“) oder er misslingt (dann ist dieser „rot“). Das Misslingen kann als Ursache einen Fehler (Error) oder ein falsches Ergebnis (Failure) haben. Beides signalisiert via Exception (Eine Ausnahmesituation, normalerweise durch Fehler hervorgerufen). Der Unterschied zwischen den beiden Begriffen liegt darin, dass man Failures erwartet, während Errors eher unerwartet auftreten. 

Technisch betrachtet, sind Failures mittels einer speziellen Exception namens AssertionFailedError gekennzeichnet. Die Interpretation aller übrigen Exceptions erfolgen vom JUnit-Framework durch Errors.

JUnit im Softwareentwicklungsprozess

JUnit ist ein wichtiges Hilfsmittel im Extreme Programming und unterstützt in diesem Zusammenhang die Idee des Extreme Testing. Als Programmierer schreibt man zuerst einen automatisch wiederholbaren (JUnit-)Test und dann den zu testenden Code.

Der Test selbst ist ebenfalls ein Stück Software und ebenso wie der zu testende Code ist dafür die Programmierung notwendig.

Wenn man zu einem späteren Zeitpunkt den Code eines anderen Programmierers zum Ändern beabsichtigt, so ruft man zuerst alle JUnit-Tests auf, um sich zu vergewissern, dass der Code vor der Änderung fehlerfrei ist. Dann führt man die Änderung durch und ruft die JUnit-Tests erneut auf. Misslingen diese, so hat man die Erkenntnis, dass man selbst Fehler gemacht hat und muss diese korrigieren. Dieser Zyklus wiederholt sich so lange, bis alle JUnit-Tests wieder fehlerfrei durchlaufen.

Dieses Verfahren wird auch „testgetriebene Entwicklung“ (englisch test-driven software development) genannt und zählt zu den agilen Methoden. Die Idee dabei ist, fehlerarmen Code zu erzeugen, indem man nichts implementiert, was man nicht auch testet. Entstehen Testfälle erst nach der Entwicklung des Codes, so ist die Wahrscheinlichkeit höher, wichtige Testfälle zu übersehen. Doch darüber habe ich bereits hier einen Artikel geschrieben.

Plugins und Erweiterungen für JUnit

Eine Implementierung von JUnit für Jakarta EE ist Cactus (ehemals J2EEUnit) aus dem Jakarta-Projekt. Seit Java EE 5 haben sich sogenannte Out-of-container-Frameworks (zum Beispiel EJB3Unit) etabliert, die eine Ausführung von Tests außerhalb eines Containers erlauben.

Erweiterungen für JUnit dienen in der Regel für den Einsatz in spezifischen Bereichen (beispielsweise httpsUnit für Webentwicklung, DBUnit für Datenbankentwicklung). Darüber hinaus gibt es noch Plugins für Entwicklungsumgebungen, die den Einsatz innerhalb der Entwicklungsumgebung ermöglichen beziehungsweise erweitern (beispielsweise Infinitest für kontinuierliches Testen oder DJUnit für Berechnung der Code-Abdeckung, englisch Code Coverage, der Tests).

Testabdeckung

Bei der Testabdeckung geht es um das Verhältnis an tatsächlich getroffenen Aussagen eines Tests gegenüber den theoretisch möglich treffbaren Aussagen bzw. der Menge der gewünschten treffbaren Aussagen. Die Testabdeckung spielt als Metrik zur Qualitätssicherung und zur Steigerung der Qualität insbesondere im Maschinenbau und der Softwaretechnik eine große Rolle.

Die Testabdeckung lässt sich durch eine Erhöhung der Zahl an Messungen, Stichproben und Testfällen verbessern. Begrenzt wird die Testabdeckung in der Praxis jedoch durch die Kosten, die mit jedem Test verbunden sind. Doch dies ist ein komplexes Thema, welches ich gerne in einem separaten Beitrag thematisiere.

Fazit

JUnit ist ein einfach zu benutzendes und leichtgewichtiges Framework für die Entwicklung von Softwaretests. Eine Integration in verschiedene IDE’s ist möglich. Dies thematisiere ich aber in den Artikeln zu den einzelnen IDE’s. Diese verlinke ich dann selbstverständlich auch hier. Die Ausführung einzelner Tests oder kompletter Testsuiten ist im Entwicklungsprozess jederzeit möglich. Nur das Programmieren der Tests kann man damit naturgemäß nicht leisten. Jedoch ist die Einstiegshürde für einen relativ guten Entwickler minimal. Es ist dabei sehr zu empfehlen, möglichst frühzeitig mit der Erstellung von Tests zu beginnen! In der Literatur beginnt die Erstellung der Tests, besonders im agilen Umfeld. Zeitgleich mit der Entwicklung selbst. Sie sind der wichtigste Bestandteil der Qualitätssicherung. Insbesondere spätere Änderungen an der Software im Rahmen funktionaler Erweiterungen oder eines Refactorings sind ohne vorhandene Regressionstests oftmals gar nicht durchführbar.

Der Beitrag JUnit – Framework für automatisierte Tests und Qualitätssicherung erschien zuerst auf CEOsBay.

Features

Im Wesentlichen unterscheiden sich die beiden Versionen im Funktionsumfang. Hierzu von der Ultimate Version unterstützte Sprachen: Java, Groovy, Kotlin, Scala, Python and Jython, Cython, Ruby and JRuby, Rust, PHP, Go, Dart, SQL, HTML, XML, JSON, YAML, XSL, XPath, Markdown, JavaScript, TypeScript, CSS, Sass, SCSS, Less, Haml, Slim, Liquid

Wobei zu beachten ist, dass die Ultimate Edition von IntelliJ IDEA neben den nativ unterstützten Sprachen, einige der Sprachen lediglich durch den Einsatz von PlugIns unterstützt. In der Community Edition sind auch einige Sprachen gar nicht berücksichtigt. Eine explizite bzw. genaue Differenzierung möchte ich in diesem Beitrag nicht vornehmen. Also sind die Angaben bzgl. der Features mit Vorsicht zu genießen.

Auch ist zu beachten, dass lediglich die Ultimate Edition von IntelliJ IDEA die umfangreiche Framework Unterstützung mitbringt. Im Enterprise Umfeld sind diese in der Regel unabdingbar.

Auch bei den Build Tools gibt es Unterschiede. Besonders auffällig ist dabei die Tatsache, dass npm zwar in der Ultimate Edition läuft, jedoch nicht in der Community Edition. Ich habe es auch in der Community Version zum Laufen gebracht. Dennoch ist dies mit Vorsicht zu genießen, da ich aufgrund von Fehlern dennoch auf die Ultimate Edition geswitched bin.

Versionskontrolle

Auf die Funktionsfähigkeit bei der Versionskontrolle bzw. bei Cloud-basierten Diensten wie Git, GitHub, Subversion, Mercurial und Team Foundation Server kann man sich verlassen. Bei Perforce ist man zumindest in der Community Edition verlassen.

Deployment

Während die Community Edition lediglich Docker für das Deployment unterstützt sind es mit der Ultimate Edition Kubernetes, Java Applications Servers als auch Docker.

Codevervollständigung

Die Codevervollständigung ist eine Funktion, die vor allem Programmieranfängern sehr entgegenkommt. Nur wenige werden als Coder geboren, oder!? Da vergisst man schon mal schnell eine import-Anweisung, IDEA aber nicht. Meistens weist IntelliJ einen auf den Fehler hin und schlägt Korrekuren vor. Dies gilt auch für nicht verwendete Importe, die IntelliJ entsprechend einer manuellen Zustimmung entsorgt.

Es nimmt einem den Grossteil der Tipparbeit ab, damit man sich dem Programmdesign widmen kann und nicht über korrekt formulierte JAVA-Anweisungen nachdenken muss. Ich muss gestehen, dass ich mich bisher noch nicht wirklich mit JAVA auseinandergesetzt habe. Doch dies hole ich derzeit nach und auch darüber gibt es in der nahen Zukunft einen Beitrag.

Code Layout Manager

Den Code Layout Manager weiß man spätestens dann zu schätzen, wenn man im eigenen Quelltext nicht mehr durchblickt oder fremden Quelltext bearbeiten muss. Dann kann man Text markieren und von IDEA neu formatieren lassen. Dies geht relativ intelligent von statten.

Refactoring

Auch die Refactoringfähigkeiten von IntelliJ sind nicht zu unterschätzen. Wer die Funktionen einmal in Aktion erlebt hat, der möchte sie nicht mehr missen. Dazu gehören u.A. das Renaming, Move, Introduce Explaining Variable, Extract Method usw.

Fazit

Ich arbeite noch nicht lange mit dem Programm. Doch IntelliJ hat scheinbar in enger Kooperation mit den Anwendern ein relativ gutes Produkt entwickelt, mit dem man gut im Enterprise Umfeld arbeiten kann. Besonders die große PlugIn Bibliothek als auch die individuelle Erweiterbarkeit durch eine offen gelegte API haben mir persönlich sehr gefallen. Dadurch ist es auch möglich eigene PlugIns für IntelliJ zu schreiben und diese zu selbst zu implementieren.

Der Beitrag IntelliJ IDEA – Die intelligente und leistungsstarke Entwicklungsumgebung erschien zuerst auf CEOsBay.

Hintergrund von Visual Studio Code

Visual Studio Code (VS Code) ist ein plattformübergreifender Open-Source-Code-Editor von Microsoft. Er wurde erstmals im Jahr 2015 veröffentlicht und hat sich seitdem kontinuierlich weiterentwickelt. Der Editor unterstützt Windows, macOS und Linux. Es bietet Entwicklern eine nahtlose und einheitliche Erfahrung über verschiedene Plattformen hinweg.

Eine kurze Zeitreise

Visual Studio Code entstand als Teil von Microsofts Bemühungen, Entwicklern leichtgewichtige, leistungsfähige und plattformübergreifende Werkzeuge zur Verfügung zu stellen. Die Geschichte von Visual Studio Code reicht zurück bis ins Jahr 2011. Als Erich Gamma, einer der Erfinder des berühmten Design-Patterns-Buchs und der Eclipse-Plattform, bei Microsoft anfing. Zusammen mit anderen Entwicklern arbeitete er an einem Projekt namens „Project Monaco“. Es begann als Experiment, um browserbasierte Entwicklungs-Umgebungen zu erforschen.

Project Monaco fokussierte sich darauf, eine leistungsfähige, webbasierte Code-Editing-Umgebung zu schaffen. Genutzt von mehreren Microsoft-Produkten wie Azure DevOps (früher Visual Studio Online) und OneDrive. Im Laufe der Zeit vergrößerte sich das Projekt immer weiter. Das Team erkannte schon bald, dass die wachsende Codebasis und die leistungsstarken Funktionen das Zeug zu einem eigenständigen Produkt hatten.

Am 29. April 2015 stellte Microsoft Visual Studio Code erstmals während der Build-Konferenz in San Francisco vor. Es war von Anfang an als Open-Source-Projekt konzipiert und steht unter der MIT-Lizenz der Masse zur Verfügung. Seit der ersten Veröffentlichung hat VS Code eine große Entwickler-Community angezogen, die ständig zur Verbesserung des Produkts beiträgt.

Mit der Veröffentlichung von Visual Studio Code verfolgte Microsoft eine neue Strategie. Sie öffneten die Pforten zu der Technologie und zu den Werkzeugen für Entwickler aller Plattformen und Programmiersprachen. VS Code war eines der ersten Produkte, das diese neue Richtung widerspiegelte. Heute ist VS Code einer der am häufigsten verwendeten Code-Editoren. Darüber hinaus hat es dazu beigetragen, das Bild von Microsoft als Unternehmen zu verändern. Ein Bild der Offenheit und Zusammenarbeit in der Entwicklergemeinschaft.

Hauptmerkmale von Visual Studio Code

• Syntax-Hervorhebung und IntelliSense: VS Code unterstützt Syntax-Hervorhebung für eine Vielzahl von Programmiersprachen. Es bietet Entwicklern eine klar strukturierte und leicht verständliche Darstellung des Codes. IntelliSense ist eine intelligente Code-Vervollständigungsfunktion. KI-Algorithmen helfen dabei, den Code effizienter und schneller zu schreiben. Dies passiert, indem es automatisch Vorschläge für Variablen, Funktionen und andere Code-Elemente anzeigt.

• Git-Integration: Die Integration von Git ermöglicht es Entwicklern, direkt aus dem Editor heraus Änderungen am Code vorzunehmen. Sowohl das committen und mit Remote-Repositories zu synchronisieren sind möglich. Darüber hinaus erfolgt die Anzeige der Änderungen im Code direkt im Editor. Dadurch kann man leichter erkennen, was, wer, wann verändert hat.

• Debugging: VS Code bietet umfangreiche Debugging-Möglichkeiten für viele Programmiersprachen und Plattformen. Es ermöglicht das Anlegen von Breakpoints, das Verfolgen von Variablenwerten und das Ausführen von Code schrittweise. Dies hilft Entwicklern, Fehler effizienter zu finden und zu beheben.

• Anpassung und Erweiterbarkeit: VS Code ermöglicht es den Nutzern, den Editor individuell anzupassen und mit zusätzlichen Funktionen zu erweitern. Es gibt eine Vielzahl von Plugins und Erweiterungen, die man im Visual Studio Code Marketplace finden und installieren kann.

• Terminal-Integration: VS Code integriert das Terminal direkt in den Editor. Dadurch kann man problemlos Terminal Befehle direkt im Editor ausführen. Auch die Build-Tools lassen sich direkt darüber verwenden. Folglich muss man den Editor nicht verlassen, um auf die Befehlszeile zuzugreifen.

• Code-Navigation und -Refactoring: Mithilfe von Funktionen wie „Go to Definition“, „Find All References“ und „Rename Symbol“ können Entwickler ihren Code effizienter navigieren und organisieren. Diese Funktionen machen das Code-Refactoring leichter und fördern die Erstellung von sauberem, gut strukturiertem Code. Nachdem ich erst kürzlich diese Funktion in IntelliJ auch recht vorteilhaft fand noch der Verweis auf den Beitrag.

• Unterstützung von Programmiersprachen und Frameworks: VS Code unterstützt eine Vielzahl von Programmiersprachen und Frameworks. Darunter JavaScript, TypeScript, Python, C#, C++, Java, PHP, Ruby, Go, Rust und viele mehr. Dank der Unterstützung von zahlreichen Frameworks wie Angular, React, Vue.js, Django und .NET Core sind Entwickler in der Lage, in ihren bevorzugten Sprachen und Umgebungen zu arbeiten.

• Arbeitsbereiche und Multifunktionsfenster: VS Code ermöglicht das Öffnen mehrerer Projekte und Arbeitsbereiche gleichzeitig und unterstützt auch das Teilen von Fenstern, sodass man problemlos mehrere Dateien nebeneinander anzeigen und bearbeiten kann. Dies erleichtert die Zusammenarbeit an komplexen Projekten erheblich.

• Live Share: Mit der Live Share-Funktion können Entwickler ihre Arbeitsbereiche in Echtzeit mit anderen teilen und gemeinsam am Code arbeiten. Dies ist besonders hilfreich für Teamarbeit, Pair-Programming und das Lösen von Problemen gemeinsam mit Kollegen.

Fazit

Visual Studio Code ist ein mächtiges und vielseitiges Tool für Entwickler, das sich in den letzten Jahren zu einem unverzichtbaren Bestandteil der Softwareentwicklung entwickelt hat. Durch die kontinuierliche Weiterentwicklung und die Anpassungsfähigkeit des Editors befindet sich VS Code mit an der Spitze der IDE’s bzw. Code Editoren und hilft Entwicklern dabei, produktiver und effizienter zu arbeiten. Obwohl es viele großartige Funktionen in Visual Studio Code gibt, ist es wichtig, sich daran zu erinnern, dass kein Tool oder Editor perfekt ist. Davon abgesehen hat jeder Entwickler seine eigenen Präferenzen und Arbeitsweisen. Wenn man jedoch auf der Suche nach einem leistungsstarken, anpassungsfähigen und umfangreichen Code-Editor ist, kann man Visual Studio Code auf jeden Fall in Betracht ziehen.

Der Beitrag Visual Studio Code – Das leichte Schwergewicht 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.