Make Eclipse RCP gradle again CI von Eclipse RCP ......Catchphrase 09.03.2017 Dresden CI von Eclipse...
Transcript of Make Eclipse RCP gradle again CI von Eclipse RCP ......Catchphrase 09.03.2017 Dresden CI von Eclipse...
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