Catchphrase

09.03.2017 Dresden

CI von Eclipse RCP Anwendungen mit

Gradle/JenkinsJohannes Tandler

Michael Barth

Make Eclipse RCP gradle again

Agenda

1. Eclipse IDE

2. Eclipse RCP

3. Repositories I

4. Architecture

5. Repositories II

6. Gradle/Jenkins/CI

7. BuildMonkey

Visualisierung von MaschinendatenMobile HMI in der Industrie 4.0

HMI SUITE - MONKEY WORKS GMBH

● Entwicklungsumgebung für Maschinenvisualisierung

○ Eclipse RCP-Applikation

○ Nutzung vieler Eclipse-Technologien

■ Grafische & Textuelle (DSL) Editoren

○ Codegenerierung

● Serverkomponente (ProcessHub)

● Bibliotheken für mobile Plattformen

Der konkrete Fall

Es war einmal … Eclipse

Eclipse IDE

● Release 2001 als IDE mit Schwerpunkt JAVA

● 2004 Wechsel auf OSGI-Basis (Equinox)

● Riesiges Universum an Projekten und Distributionen

● Multi - Language Support

Geschichte

Heute

Eclipse RCP

● Eclipse zugrundeliegendes Applikationsframework

● Eclipse und jede Variante davon ist eigene RCP - Applikation

● XMind, IBM Rational Developer

● MONKEY WORKS HMI Suite Workbench

● Dependency Injection, Services, Build tooling

Abbildung: Eclipse RCP-Applikation XMind

Eclipse RCP

● Produkt = Features + Plugins + Configuration + Assets + Binaries

● Feature = Plugins + Andere Features

● Ein Plugin (Projekt) = Java Bibliothek + zusätzliche Konfiguration

● Eclipse RCP Produkt = Target Platform + Product File + Magie

Theorie

Praxis

Eclipse RCP

● Eigenes Buildsystem (PDE)

● Eigenes Dependency- management

○ Als Teil der MANIFEST.MF

● Eigenes Management von Repositories und Nutzung derer

○ Target-Platform Abbildung: Target-Platform Definition

Eclipse provisioning platform - P2

● Provisioning Platform für OSGI-Applikationen

● Veröffentlichung mit Eclipse Ganymede

● Als Ersatz des alten Update - Mechanismus

Abbildung: Logo von Eclipse Ganymede

Geschichte

Eclipse P2

● Repository

○ Metadata

■ Installable Unit

● Feature

● Plugin

○ Artifact

Abbildung: Begrifflichkeiten in der P2-Domäne

Begriffe

Eclipse P2Struktur

● Trennung von

○ Metadaten :Beschreibung von Inhalt und Abhängigkeiten

○ Artefakten :URL, Artefaktgröße, Hash, etc.

● Zentraler Index notwendig

Abbildung: Beispiel eines P2-Repositories

Eclipse P2Architektur

Abbildung: Architektur von Eclipse P2

Maven

● Build-Management-Tool für Java-Projekte

● Deskriptiver Ansatz

● Repository-Format von anderen Buildwerkzeugen adoptiert

○ Umfangreiche Unterstützung

Konvention vor Konfiguration

Geschichte:

● Release 1.0 im Jahr 2002

● Release 3.0 im Jahr 2010

● Aktuell Version 3.3.9

Maven

● Project

○ Pom

○ Dependencies

○ GroupID

● Artifact

Abbildung: Beispiel einer pom.xml aus der offiziellen Mavendokumentation

Begriffe

Maven

Project Object Model

DependencyManager

Project lifecycle

plugin plugin plugin

src gen bin

pom’sM2

Repository

Abbildung: Architektur von Maven

Architektur

MavenStruktur

● Gesamtes Repository ist an einem Ort gespeichert

● Konvention für Ordnerbenennung

● Buildbeschreibung (Pom) wird mitgespeichert

● Kein zentraler Index notwendig

Abbildung: Beispiel eines Maven Repositories

Build

Das sollte doch ganz einfach sein...

Plugin - Projekt

Problematik

External P2

External M2

Eclipse

MFsrc

Buildtool

Exist. Lösungsansätze

● Umwandlung von Maven- Abhängigkeiten in Eclipse Plugins

● Bereitstellung mit P2-Repository

Eclipse Orbit

Eclipse Projekte

● Verschiedene Eclipse Projekte deployen Artefakte nach Maven Central

Exist. Lösungsansätze

● Sammlung von Maven-Mojos für Eclipse Projekte

● Erlaubt den Zugriff auf P2-Repositories mit Maven

● Erlaubt den Zugriff auf Maven-Abhängigkeiten aus Eclipse-Plugins (m2e)

● Produkterstellung möglich

Tycho

P2

Maven / Tycho

lokalesP2

lokalesM2

Build

M2

Produkt

Abbildung: Funktionsweise von Maven / Tycho

Buildsystem - Alt

● Codebasis XXX.XXX Zeilen

● 3+ Programmiersprachen

● Branchspezifische Builds

● Produktdeployment für Master

➔ Buildzeiten von 2 Stunden➔ Inkonsistente Builds➔ Komplex➔ Keine Abhängigkeitspflege➔ Kein Continuous Delivery

Buildsystem - Wünsche

● Viel kürzere Buildzeiten

● Deployment von Branches möglich

● Leichtere Pflege von Abhängigkeiten durch Entwickler

● Komplette Isolation von Buildzweigen

● “Continuous Delivery”

Lösungsidee

● Reduzierung von Maven

● Buildtool soll sich nach Entwicklung richten nicht andersherum

○ Manifest First

○ Integration von externen Abhängigkeiten in Eclipse

○ Keine exotischen Eclipse-Plugins

● Persistenz von Abhängigkeiten

Wünsche

Lösungsarchitektur

Plugin - Projekt

External P2

External M2

Eclipse

MFsrc

gradle

Internal P2

Internal M2

gradle - build

gradle - p2

gradle - m2

Repositories II

● OSGi-Repository○ Im P2 und M2 Format○ Beinhaltet alle Abhängigkeiten aus Eclipse-Ökosystem○ Unterstützt Branching

● Thirdparty-Repository○ Im P2 und M2 Format○ Umfasst alle Abhängigkeiten aus externen Quellen○ Unterstützt Branching

● Feature/Branch-Repositories○ Im M2 Format○ Umfasst Buildartefakte des jeweiligen Branch

Buildpipeline

Wenn Sie jetzt noch wach sind ...

Gradle/Jenkins/CI

Continuous Integration

SCM

SourceScripts

Development

Build Server

Build Artefacts

Artefact Server

Build Process

Dependen-cies

Eclipse

JavaGradle

Git

Jenkins

Jenkins DSLGradle tasks

MavenArtefacts

Artifactory

Maven Artefacts

Erstellen der Target Platform

Gradle/Jenkins/CI

● gradle publishTargetPlatform

Public P2 Reposi-tories

Mirror task

Artifactory/ Osgi/m2

Artifactory/Osgi/p2

Mavenize task Local Maven Repository

One local P2 Repository

Target Platform

Source Platform

Upload tasks

Target file task

Publish target file task

Git/TargetPlatforms

● gradle createTargetPlatform

● gradle artifactoryUpload_1

● gradle artifactoryUpload_0

● gradle mavenizeP2Repository

● gradle mirrorP2Repository

Erstellen des Third Party Features

Gradle/Jenkins/CI

Maven Reposi-tories

Update site task

Artifactory/ Thirdparty/m2

Artifactory/Thirdparty/p2

Mavenize task Local Maven Repository

One local P2 Repository

Target Platform

Libraries

Upload tasks

Update Target file task

Git/TargetPlatforms

● gradle updateTargetPlatform

● gradle artifactoryUpload_1

● gradle artifactoryUpload_0

● gradle mavenizeP2Repository

● gradle updateSite (bnd-tools)

Gradle/Jenkins/CI

Aufbau eines Features

● Plugins als Unterprojekte● Root Gradle Script, Jenkins Script,

Feature Properties

Aufbau eines Plugins

● Source- Verzeichnis Maven- konform

● Manifest Datei, Eclipse Projekt Dateien, Plugin Properties

Gradle/Jenkins/CI

Bauen eines Features

Feature aus SCM

Gemeinsame Gradle Skripte

build (assemble, test, check)

publish

trigger upstream

Gradle/Jenkins/CI

Erstellen eines Produktes

bnd-tools updateSite

.product

gradle publishProduct

prepareProduct

materialise

Feature list

lokales P2

Produkt

BuildMonkey

● Open Source Projekt initiiert von MONKEY WORKS● https://github.com/MONKEY-WORKS/BuildMonkey● Ziel ist die Abbildung der gesamten Buildpipeline in gradle● gradle → build.gradle → commons.gradle → Plugins● 4 Hauptprojekte:

○ ArtifactoryUpload○ Compilation○ Repository○ Materialisation

● Mitarbeit ausdrücklich gewünscht

BuildMonkey

ArtifactoryUpload

● kopiert jede Filestruktur in ein Artifactory Repository

● gradle artifactoryClearRepository● gradle artifactoryUpload_n

BuildMonkey

Compilation

● ManifestDependencyPlugin● FixDependencyVersion● ModifyBundle

BuildMonkey

Repository

● P2MirrorPlugin● MavenizerPlugin● P2DeployerPlugin● MavenArtefactsPlugin

BuildMonkey

Materialisation

● Build Product● Execute Tests

Fazit

● Buildzeiten drastisch reduziert auf 5 Minuten (komplett ca. 30 Minuten)

● Continuous Delivery ist möglich

● Buildskripte sind selten länger als 1 Bildschirmseite und lesbar

● Dependency- Pflege viel einfacher

● Branches nutzen konsistente Umgebung

● Produkte sind auch von Branches aus erstellbar

Wir danken für Ihre Aufmerksamkeitund den Projekten Wuff, Buildship,

Tycho und bnd-tools