Schlagwort-Archive: Apache Maven
Project Object Model (POM) im Detail
Maven Projekt Verzeichnissstrukturen & Archetypen
Grundlagen
Stichwortverzeichnis & Abkürzungen
[A]
[B]
[C]
[D]
[E]
[F]
[G]
[H]
[I]
[J]
[K]
[L]
[M]
[N]
[O]
[P]
[Q]
[R]
[S]
[T]
[U]
[V]
[W]
[Y]
[Z]
[X]
Zurück zum Inhaltsverzeichniss: Apache Maven Master Class
A
- agiles Manifest
- (Apache) Ant
- Archetypen (archetypes)
- Artifact (dt. Artefakt)
B
C
D
- Deploy
- Docker Maven Image
- DRY – Don’t repeat yourself [2]
- DSL – Domain Specific Language
E
- EAR – Enterprise Archive
- EJB – Enterprise Java Beans
- Enforcer Plugin
- EoL – End of Live
F
G
- GAV Parameter [2]
- Goal [2]
- GPG – GNU Privacy Guard
H
I
- IDE – Integrierte Entwicklungsumgebung
- Installation (Linux / Windows)
- inkrementelle Builds
- (Apache) Ivy
J
- JAR – Java Archive
- jarsigner Plugin
- JDK – Java Development Kit
K
- Keytool (Java)
- KISS – Keep it simple, stupid.
- Kochbuch: Maven Codebeispiele
L
M
N
O
- OWASP – Open Web Application Security Project [2]
P
- Plugin
- Production Candidate
- POM – Project Object Model
- Maven Properties
- Prozess
Q
R
S
T
- target – Verzeichnis
- Token Replacement
U
V
W
- WAR – Web Archive
X
Y
Z
[A]
[B]
[C]
[D]
[E]
[F]
[G]
[H]
[I]
[J]
[K]
[L]
[M]
[N]
[O]
[P]
[Q]
[R]
[S]
[T]
[U]
[V]
[W]
[Y]
[Z]
[X]
Zurück zum Inhaltsverzeichniss: Apache Maven Master Class
Referenzen & Literatur
Kochbuch: Maven Codebeispiele
In unserem Git Repository befindet sich eine umfangreiche Sammlung an verschiedenen Codebeispielen für Apache Maven Projekte. Alles gut übersichtlich nach Themengebieten sortiert.
Zurück zum Inhaltsverzeichniss: Apache Maven Master Class
- Token Replacement
- Compiler Warnings
- Excecutable JAR Files
- Enforcments
- Unit & Integration Testing
- Multi Module Project (JAR / WAR)
- BOM – Bill Of Materials (Dependency Management)
- Running ANT Tasks
- License Header – Plugin
- OWASP
- Profiles
- Maven Wrapper
- Shade Ueber JAR (Plugin)
- Java API Documantation (JavaDoc)
- Java Sources & Test Case packaging into JARs
- Docker
- Assemblies
- Maven Reporting (site)
- Flatten a POM
- GPG Signer

Apache Maven Master Class
Apache Maven (kurz Maven) erschien erstmalig am 30. März 2002 als Apache Top Level Projekt unter der freien Apache 2.0 Lizenz. Diese Lizenz ermöglicht auch eine freie Nutzung für Unternehmen im kommerziellen Umfeld ohne das Lizenzgebühren fällig werden.
Das Wort Maven kommt aus dem Jiddischen und bedeutet so viel wie „Sammler des Wissens“.
Maven ist ein reines Kommandozeilenprogramm und wurde in der Programmiersprache Java entwickelt. Es gehört in die Kategorie der Build-Werkzeuge und findet vornehmlich in Java Softwareentwicklungsprojekten Verwendung. In der offiziellen Dokumentation bezeichnet sich Maven als Projektmanagement-Werkzeug, da die Funktionen weit über das Erstellen (Kompilieren) der binär ausführbaren Artefakte aus dem Quellcode hinausgehen. Mit Maven können Qualitätsanalysen von Programmcode und API-Dokumentationen erzeugt werden, um nur einige der vielfältigen Einsatzgebiete zu nennen.
Vorteile
- Zugriff auf alle Abonnementartikel
- Zugriff auf das Maven Sample Git Repository
- regelmäßige Updates
- E-Mail Support
- regelmäßige Live Video FAQ
- Video Workshops
- einreichen eigener Themenvorschläge
- 30% Rabatt auf Maven Schulung
Zielgruppen
Dieser Onlinekurs eignet sich sowohl für Anfänger ohne Vorkenntnisse, als auch für erfahrene Experten. Jede Lektion ist in sich geschlossen und kann individuell ausgewählt werden. Umfangreiches Zusatzmaterial erklärt Zusammenhänge und ist mit zahlreichen Referenzen unterlegt. Das ermöglicht Ihnen den Kurs Apache Maven Master Class auch als Nachschlagewerk zu nutzen. Kontinuierlich werden dem Kurs neue Inhalte hinzugefügt. Wenn Sie sich für eine Mitgliedschaft der Apache Maven Master Class entscheiden sollten, haben Sie außerdem vollen Zugriff auf exklusive Inhalte.

Entwickler
- Maven Grundlagen
- Maven auf der Kommandozeile
- IDE Integration
- Archetypes: Projektstrukturen anlegen
- Testintegration (TDD & BDD) mit Maven
- Testcontainers mit Maven
- Multi Module Projekte für Microservices

Buildmanager / DevOps
- Release Management mit Maven
- Deploy nach Maven Central
- Sonatype Nexus Repository Manager
- Maven Docker Container
- Docker Images mit Maven erstellen
- verschlüsselte Passwörter
- Prozess & Build Optimierung

Qualitätsmanager
- Maven Site – Die Reporting Engine
- Testabdeckung ermitteln & bewerten
- statische Codeanalyse
- Codingstyle Vorgaben überprüfen

Entwickler Tage remote 2024
Test Driven: from zero to hero
In der Softwarebranche ist es üblich, dass die Codebasis eine ausreichende Testautomatisierung aufweist. Denn dies ist für einen stabilen DevOps-Prozess und sicheres Refactoring notwendig. Aber die Realität sieht oft ganz anders aus. Fast jedes Projekt, an dem ich während meiner Karriere teilgenommen habe, hatte keine Zeile Testcode. Wenn wir darüber nachdenken, dass seit über 40 Jahren immer noch 80% aller kommerziellen Softwareprojekte scheitern, sollte uns das nicht überraschen. Aber das muss nicht so sein. In diesem Vortrag zeige ich, wie einfach es ist, auch in großen Projekten einen testgetriebenen Ansatz einzuführen. Das technische Setup ist ein Standard-Java-Projekt mit Apache Maven und JUnit 5.
PHP meets Maven – Teil 4

[Teil 1] [Teil 2] [Teil 3] [Teil 4]
Für die Integration in IDEs ist es unerheblich, bei welcher IDE Ihre persönlichen Präferenzen angesiedelt sind, der Funktionsumfang der Integration ist in beiden IDEs weitgehend identisch und unterscheidet sich nur in Details. Während NetBeans von Haus aus Maven-Projekte unterstützt, ist für die meisten Eclipse-Distributionen die zusätzliche Installation des Eclipse-Maven-Plug-ins m2e notwendig.
Der Vorteil, die Funktionalitäten von Maven innerhalb einer IDE nutzen zu können, ist enorm. Ein Aspekt ist beispielsweise der Import bestehender Maven-Projekte in die Entwicklungsumgebung. Anhand der POM werden die notwendigen Konfigurationen des gesamten Projekts wie zum Beispiel Verzeichnisse für Sourcen, Test und Dependencies aus der POM gelesen. Ein mühseliges Adaptieren der Projekteigenschaften nach einem Import entfällt ebenso wie das Verteilen der IDE-Konfiguration über das Konfigurationsmanagement. Dadurch hat der Entwickler mehr Freiheit bei der Wahl seiner Entwicklungsumgebung. Eine Grundvoraussetzung für den erfolgreichen Import eines Projekts in eine IDE ist, dass die verwendeten Dependencies lokal oder remote verfügbar sind. Hin und wieder kommt es vor, dass einzelne Artefakte manuell in das lokale Repository installiert werden müssen. Diese Aufgabe lässt sich in beiden IDEs sehr komfortabel mit wenigen Mausklicks bewerkstelligen und ein optisches Feedback des Erfolgs kann über die Views der Repository-Browser eingeholt werden.

Ältere Projekte, die nicht im Maven-Format vorliegen und damit nicht die notwendige Verzeichnisstruktur und POM aufweisen, lassen sich in den meisten Fällen über die Konsole automatisiert migrieren. Der schnellere Weg ist allerdings eine manuelle Migration, da die automatisch generierte POM in aller Regel im Nachhinein weiter von Hand angepasst werden muss. Über Archetypes werden die Verzeichnisstruktur und die POM erzeugt. Im zweiten Schritt sind die Sourcen et cetera in die entsprechenden Verzeichnisse zu kopieren, um abschließend die Dependencies zu konfigurieren. In späteren Arbeitsschritten kann die POM den Projektanforderungen weiter angepasst werden.

Eine wichtige Eigenschaft ist unter anderem auch die Möglichkeit, das vorhandene Maven Build-in der IDEs durch eine eigene Maven-Installation auszutauschen. Der Vorteil einer externen Installation ergibt sich aus dem größtmöglichen Einfluss auf den Entwicklungsprozess, da beispielsweise festgelegt wird, welche Version von Maven verwendet wird. Vor allem, wenn stets auf die neueste Version zurückgegriffen werden soll, ist diese Option von unschätzbarem Wert, das es meist einige Zeit dauert, bis das entsprechende Plug-in aktualisiert wird.
Die größten Unterschiede zwischen NetBeans und Eclipse finden sich bei der Bearbeitung der POM. Während NetBeans auf eine Code-Vervollständigung setzt, bietet Eclipse einen grafischen POM-Editor. Für den korrekten Betrieb von Maven ist die Auszeichnung der Schemadefinition der POM nicht notwendig. Das Weglassen der XML-Schemadefinition quittiert Eclipse mit einer Fehlerausgabe, die folgende Auszeichnung des <project> Tags beendet die Belästigung umgehend:
<project
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
XML

Das Anstoßen der einzelnen Build-Lifecycles aus Eclipse oder NetBeans heraus ist mittlerweile recht intuitiv. Der Übersichtlichkeit wegen werden nur die wichtigsten Phasen der Lifecycles zum direkten Ausführen über die Toolbar beziehungsweise das Kontextmenü angeboten. Dazu zählen vor allem Build, Clean, Clean Build und Test. Wenn dennoch einmal ein spezielles Goal gestartet werden muss, bieten beide IDEs die Möglichkeit, über einen Wizard die entsprechende Phase mit dem gewünschten Goal zu konfigurieren und auszuführen. Im Screenshot ist beispielhaft die Run-Konfiguration von Eclipse abgebildet. Für php-maven Projekte existiert ein Eclipse-Plug-in, das von Martin Eisengart entwickelt wurde. Aktuell ist dazu eine neue Version für Eclipse Indigo erschienen. Eine wichtige Eigenschaft dieses Plug-ins ist die Konvertierungsfunktion für Maven-Projekte nach php-maven. Nach erfolgreicher Konvertierung zeigt Eclipse in der View Problems den Fehler, dass das maven-plugin-Plug-in nicht ausgeführt werden kann. Diese Meldung ist kein wirklicher Fehler, sondern ergibt sich aus den Restriktionen des m2e-Plug-ins, das für alle unbekannten Plug-ins Fehler ausgibt.

Sehr komfortabel ist das Generieren der Site über das Plug-in. Dazu hält der Menüeintrag die Punkte generate, view und deploy bereit. Besonders angenehm ist die Option, die generierte Seite im Browser auszugeben, ohne umständlich über das Target-Verzeichnis navigieren zu müssen.
Wenn die Testfälle über das Kontextmenü in das Projekt eingebunden wurden, kann die View PHPUnit die wichtigsten Informationen der durchlaufenen Testfälle visualisieren. Neben den Testergebnissen wird auch eine Coverage ausgegeben (Bild 6).

Berichtswesen
Neben dem Build- und Clean-Lifecycle existiert als Dritter im Bunde der Site-Lifecycle, mit dem Reports und sogar komplette Webseiten automatisch generiert werden können. Ein gutes Beispiel der Site-Generierung ist die Homepage des php-maven Projekts, die mit Maven erzeugt wurde.
Innerhalb der POM können verschiedene Angaben zu wichtigen Projektinformationen gemacht werden, die über eine Projektseite publiziert werden können. Typische Informationen sind unter anderem der Projektname mit einer Kurzbeschreibung, dem Gründungsjahr und der Lizenz des Artefakts. Neben diesen allgemeinen Informationen können auch die URLs zu CI-Servern, Sourcecode-Repositories, Mailing-Listen und beteiligten Personen angegeben werden. Die notwendigen Einträge der POM zeigt Listing 1.
<licenses>
<license>
<name>BSD 3-Clause</name>
<url>http://www.opensource.org/licenses/BSD-3-Clause/</url>
</license>
</licenses>
<name>CMS</name>
<description>
A Collection of diffrent Modules for a CMS.
</description>
<url>https://elmar-dott.com</url>
<inceptionYear>2012</inceptionYear>
<scm>
<url>https://git.elmar-dott.com</url>
<connection>https://git.elmar-dott.com</connection>
<developerConnection>https://git.elmar-dott.com</developerConnection>
</scm>
<issueManagement>
<system>Redmine</system>
<url>https://issues.elmar-dott.com/</url>
</issueManagement>
<ciManagement>
<system>Jenkins</system>
<url>http://localhost/jenkins</url>
</ciManagement>
<developers>
<developer>
<name>Elmar Dott</name>
<id>ed</id>
<email>ed@elmar-dott.com</email>
<roles>
<role>Release-Management</role>
</roles>
<organization>Elmar Dott Consulting</organization>
<organizationUrl>https://elmar-dott.com</organizationUrl>
<timezone>+1</timezone>
</developer>
</developers>
Um der Seite statische Inhalte zuzufügen, stehen unterschiedliche Mechanismen zur Auswahl. Grundlegend ist das Verzeichnis site unterhalb von src im Projektverzeichnis anzulegen, in dem unter anderem auch der Site-Deskriptor hinterlegt wird. Über den Site-Deskriptor site.xml werden unter anderem die Navigation zusammengebaut und zusätzliche Inhalte hinzugefügt. Es können drei unterschiedliche Content-Typen erzeugt werden: APT (Almost Plain Text) ist ein an Wiki Style angelehntes Format, während fml eine FAQ-Struktur erzeugt und überwiegend in Maven-1-Projekten zum Einsatz kam. Am verbreitetesten ist xDoc, ein XML-basiertes Format, um Inhalte zu erstellen.
Um der Seite verschiedenste Reports hinzuzufügen, ist das Site-Plug-in entsprechend zu konfigurieren. Der übliche Weg über den Abschnitt <reports>
ist mittlerweile als deprecated gekennzeichnet und sollte nicht weiter verwendet werden. Um nicht benötigte Reports auszusparen, werden diese in der Konfiguration des <reportSets>
weggelassen. Auf der Maven-Plugin-Seite finden sich noch weitere Plug-ins zu Reports, beispielsweise das Checkstyle-Plug-in, um den Code auf die Einhaltung festgelegter Style-Guides zu prüfen.
- Teil 1 – Einführung, CoC, DRY
- Teil 2 – POM, Testen & API Dokumentation
- Teil 3 – Web-Anwendungen mit Maven
- Teil 4 – IDE-Integration