Category Archives: Werkzeuge

Werkzeuge

DSL Projekt aufsetzen (mit Xtext)


Flattr this

Motivation

Da es ein wenig Mühe bereitet hat und ich nach einem Jahr nicht noch einmal den Aufwand investieren möchte schreibe ich hier eine kleine Anleitung wie man ein DSL Projekt unter folgenden Randbedingungen aufsetzt:

  • Als Entwicklungsumgebung wird eclipse eingesetzt
  • Zur Sicherstellung einer einheitlichen eclipse Installation wird yatta-profiles genutzt
  • Zur Modellierung der DSL wird Xtext verwendet
  • Die Sourcen werden auf github.com gehostet
  • Als CI System kommt travis-ci.org zum Einsatz
  • Zur Verteilung der Releasestände wird bintray.com genutzt

Die Eclipse aufsetzen

Lange habe ich nach einer Möglichkeit gesucht um diesen Schritt zu automatisieren. Angefangen über das Niederschreiben der Installation hier im Blog (Eclipse konfigurierenEclipse aufsetzen) über CloudConnect bin ich letztlich auf Yatta-Profiles gekommen. Yatta Profiles hat sich für meine Arbeitsweise als am besten geeignet erwiesen um die zu installierenden Plugins und die aus zu checkenden Projekte einheitlich für ein Team zu verteilen (Allerdings nutze ich das Angebot nicht als Team sondern als einzelner Entwickler. Halte mir aber die Möglichkeit offen mit mehreren Leuten zu gleich an einem Projekt zu entwickeln.)

Bleibt das Speichern der eigentlichen Konfiguration der installierten Plugins. Diese Arbeit kann ich an das Oomph Plugin delegieren. Zum Glück hat das Projekt jetzt eine Reife erlangt die zur produktiven Arbeit genügen sollte. 

Wer meine Eclipse Installation ausprobieren möchte, kann sich einfach das Yatta-Profile installieren: ECLIPSE XTEXT DSL TOOLS

Die Sourcen erstellen

Generell beginne ich mit dem Anlegen eines leeren Repositories (Projekt) auf Github. Dabei wähle ich zunächst den Namen aus, dann gebe ich java als Programmiersprache an und wähle eine mir genehme Lizenz aus. Weiterhin selektiere und aktiviere ich die Checkbox „Readme erstellen“. Nach dem Fertigstellen bietet github.com ein neues Projekt zum clonen an und genau das mache ich dann auch – ich klone das Projekt mittels git clone <url> in ein lokales Verzeichnis auf meinem PC. 

Nun starte ich eclipse und erzeuge über den Dialog „Neu/Projekt/Xtext“ ein neues xtext Projekt.

Hierbei sind bereits ein paar wichtige Dinge zu beachten. Da ich später auf bintray deployen möchte benötige ich eine einheitliche GroupId über alle Projekte hinweg. Gern hätte ich hier com.github.funthomas424242.dsl verwendet, doch das funktioniert nicht mehr falls ich mal ein Maven Plugin entwickeln sollte dann hätte ich nämlich gern die gropuId com.github.funthomas424242.maven.plugins verwendet. Damit bräuchte ich aber zwei groupId’s und das würde zwar gehen aber ist von bintray nicht gewünscht. Da man nie weiß wann solche Wünsche mal in Vorgaben umgewandelt werden (besonders wenn man die kostenlosen Services nutzt) habe ich mich also für die groupId com.github.funthomas424242 entschieden. Als Folge daraus muss ich meine Projekte mit dieser groupId versehen. Damit das funktioniert und ich trotzdem noch verschieden DSL Projekte verwalten kann gehe ich wie folgt weiter vor. 

Die nachfolgenden Einstellungen im Wizard werden am Beispiel meines Projektes ahnen.dsl auf github erklärt. Und so fülle ich die erste Dialogseite des Wizards aus:

Xtext Projekt Basisdaten

 

Ja, der Projektname ist richtig. Zwar wird dieser als groupId verwendet doch lässt sich das später manuell gut abändern.

Xtext Projekt Settings

 

Als Source Layout wurde Plain gewählt da eine andere Kombination mit der Einstellung Eclipse Plugin aktuell noch nicht unterstützt wird.

Nun werden diverse Projekte vom Wizard in der eclipse erzeugt.  Von jedem Projekt öffnen wir nun die pom.xml und korrigieren die groupId manuell auf z.B. com.github.funthomas424242 Anschließend selektieren wir alle Projekte und führen ein Maven update Projekt über das Kontext Menü in der eclipse durch. Nun sollten alle Projekte wieder fehlerlos erscheinen. Falls nicht einfach die Xtext Datei öffnen und noch mal alle Sourcen generieren lassen. 

Bevor wir einen commit durchführen sollten wir noch im parent Projekt eine .gitignore anlegen. Meine sieht wie folgt aus:

.settings/
target/
src-gen/
xtend-gen/
.project
.classpath
*_gen

Man beachte, dass ich hier die führenden / (Slashes) weggelassen habe damit die Regeln auch für die Unterprojekte gelten. Nun testen wir zunächst unser Projekt indem wir eine Eclipse Instanz mit Runtime Workspace starten:

Runtime Start

 

In der gestarteten Runtime Eclipse legen wir ein einfaches Projekt „Test“ an und darin eine Datei test.ahnen. Beim Öffnen dieser Datei können wir sehen ob unser Plugin prinzipiell schon funktioniert, denn es muß der entsprechende Editor zum Öffnen angeboten werden. In meinem Fall nennt sich dieser Ahnen Editor und ist vorhanden. Verwenden wir diesen Editor zum Öffnen werden wir gefragt ob das Projekt in ein Xtext Projekt konvertiert werden soll – ja natürlich. Wir müssen nichts dazu tun eclipse trägt nun ein paar Metadaten in die Projektbeschreibungsdatei .project ein und das scheint es gewesen zu sein. Den Editor prüfen wir indem wir seine Vorschlagsfunktion unter Ctrl+Space nutzen und den ganzen Beispieltext damit eingeben.

Das war es erstmal. Jetzt können wir die Runtime Instanz der eclipse schließen und unseren Projektstand commiten (aber noch nicht pushen). Wir müssen zwar noch alle Projekte ein Verzeichnis nach oben verschieben aber das sollte git als Verschiebung erkennen und somit sollte dies kein Problem ergeben. Also commited ist.

Jetzt löschen wir alle Projekte aus unserer eclipse aber nicht auf der lokalen Festplatte!!!

Nun unbedingt die eclipse schließen da sie meist die Projekte trotzdem noch lockt und dadurch nachfolgende Schritte fehlschlagen würden. 

In einer Shell navigieren wir jetzt zum Parent Projekt (in diesem ist die pom.xml des parents zu finden) von dort aus verschieben wir alle Verzeichnisse und Dateien ins übergeordnete Verzeichnis. Anschliessend navigieren wir selber in das übergeordnete Verzeichnis und löschen das nun leere alte parent Projekt.

Jetzt ist unser normales root Verzeichnis aus dem github repository das parent Projekt und wir können es ganz normal in  unsere Eclipse neu importieren. 

Diesen Stand commiten wir ebenfalls wobei wir ihn dem letzten Commit hinzufügen (amend commit). Jetzt noch ein kurzer Test mit der Runtime eclipse. Wenn alles noch so funktioniert wie vorher, dann können wir jetzt pushen.

Maven Build anpassen

Durch die manuelle Umbenennung der groupId haben wir unser Definitionsfile der target platform invalidisiert. Das sollten wir unverzüglich beheben. Das Problem wird deutlich wenn wir im Root Verzeichnis unseres Projektes ein mvn clean install ausführen.

Das Problem lässt sich leicht korrigieren durch eine Anpassung in der parent/pom.xml. Dort muss die groupId der TargetPlatform angepasst werden. Ich bevorzuge eine generische Lösung. Anbei der relevante Abschnitt aus der parent/pom.xml:

<plugin>
 <groupId>org.eclipse.tycho</groupId>
 <artifactId>target-platform-configuration</artifactId>
 <version>${tycho-version}</version>
 <configuration>
  <target>
   <artifact>
    <groupId>${project.groupId}</groupId>
    <artifactId>com.github.funthomas424242.dsl.ahnen.target</artifactId>
    <version>${project.version}</version>
   </artifact>
  </target>

So jetzt funktioniert der Maven Build wieder. Zeit für einen neuen commit. Aber mit dem Push ruhig noch warten, den wollen wir gleich durch das CI System schicken.

Das CI System aktivieren

Dazu gehen wir auf travis-ci.org und loggen uns mit unserem github.com Account per OAuth ein. In der rechten oberen Ecke wird der Nutzername angezeigt beim überstreichen mit der Maus ploppt ein Menü auf. Daraus wählen wir den Punkt Accounts aus. Da das Repository neu ist, wird es travis-ci noch nicht kennen und wir nutzen den Sync Button oben rechts um unsere github Projekte zu importieren. In der erscheinenden Liste an Projekten suchen wir unser Projekt und aktivieren den Schalter davor. Ab jetzt sucht travis-ci bei jedem push in das Projekt eine Datei .travis.yml und falls gefunden wird anschließend ein Build ausgeführt.

Natürlich müssen wir diese Datei noch ins Projekt einchecken. Sie gehört ins parent Projekt und muss wirklich mit einem Punkt beginnen (also ein Problem für alle Windows Freunde – aber ein lösbares 🙂 )

language:
 - java

jdk:
 - oraclejdk8

Nun noch ein commit und ein push und die Maschinerie springt an 🙂 Nach ungefähr 10 Minuten sollte das Projekt in travis erscheinen und der Build lässt sich prüfen. Es empfiehlt sich ein entsprechendes Build Icon von travis in die Projekt Readme zu integrieren. So kann man auf einem Blick erkennen wenn der Status auf rot geht. 

Bintray Deployment anbinden

Zu den Formalitäten wie Registrierung und ähnliches bei bintray.com möchte ich hier nicht eingehen. Nur eins dazu das Passwort für die oss.jfrog.org Seite ist Euer API Key von bintray.com. Möglicherweise müsst ihr Euch erst freischalten lassen etc. Aber das sollte sich jeder selbst durchlesen, da es teilweise auch Sicherheitsrelevant ist.

Weiterhin ist bei maven die settings.xml anzupassen. Hier sind die Zugangsdaten für den Server zu hinterlegen. Vorsicht – die Datei darf kein Anderer in die Hände bekommen. Idealerweise nutzt ihr die Verschlüsselungsmechanismen. 

Im Projekt ist auch noch eine Anpassung durchzuführen. Die Deplyoment Repositories sind im parent/pom.xml bekannt zu geben. Dazu fügen wir folgenden Eintrag in die parent/pom.xml ein.

<distributionManagement>
 <snapshotRepository>
  <id>snapshots</id>
  <name>oss-jfrog-artifactory-snapshots</name>
  <url>https://oss.jfrog.org/artifactory/oss-snapshot-local</url>
 </snapshotRepository>
 <repository>
  <id>bintray-funthomas424242-dsl</id>
  <name>oss-jfrog-artifactory-releases</name>
  <url>https://oss.jfrog.org/artifactory/oss-release-local</url>
 </repository>
</distributionManagement>

Mit einem mvn deploy lassen sich ab jetzt Snapshots und Releases nach oss.jfrog.org deployen. Von dort aus können diese im angemeldeten Zustand über das Kontextmenü nach bintray.com in ein beliebiges Package kopiert werden. Jedes Package muss auf bintray in einem Repository liegen. Ein Package welches im jCenter veröffentlicht werden soll muss einigen Anforderungen genügen (mindestens ein jar, ein src.zip, ein pom.xml und optional noch ein javadoc archive). Die Freischaltung für das jCenter dauert ein wenig Zeit – am besten rechnet man mit 24h – und erfolgt nur auf Antrag. Eine weitere Freischaltung für das maven central erfordert dann noch ein Sonatype Login. Parallel zur Beantragung der ganzen Accounts kann dann schon mal Fachlichkeit umgesetzt werden 🙂

Noch ein paar Tipps

  1. Tycho kann bereits in der Version 0.25.0 benutzt werden. Das muss man manuell in der parent/pom.xml in den Properties eintragen. 
  2. Um das Deployment zu verringern nutze ich in der parent/pom.xml:
    <maven.deploy.skip>true</maven.deploy.skip>
    und in der pom.xml des repository Subprojektes:
    <maven.deploy.skip>false</maven.deploy.skip>
    So wird nur das Zip mit der eclipse update site hochgeladen.

Soweit zum Aufsetzen eines DSL Projektes und viel  Spass beim Ausprobieren. Jetzt muss nur noch die Fachlichkeit umgesetzt werden 😉

 

Cheaten per Sheet


Flattr this

Motivation

Jeder von uns benutzt täglich eine Vielzahl an Werkzeugen. Nach längerer Pause werden die Tastenkürzel oder Kommandos vergessen. Dann greift man sich ein Cheat Sheet und schon läuft’s wieder. Auf manchen Cheat Sheets fehlt etwas, was man daher manuell per Stift ergänzt hat. Der Zettel ist nun leider weg aber ein eigenes Cheat Sheet zu entwerfen dafür fehlte immer die Zeit. Erst ein Template bauen und dann noch den Inhalt ausdenken – gibts da nicht was von der Stange? Und so fand ich Cheatography.

Cheatography

~, dies ist eine Plattform auf welcher sich auf einfachste Art einfache Cheat Sheets erstellen lassen. 

Zunächst muss man sich registrieren 😦 Ja ohne Daten geht es leider nicht und ein brauchbares Video ob sich die Registrierung lohnt war auch nicht im Netz zu finden. Darum hab ich das für Sie mal ausprobiert und muss sagen es lohnt sich.  Nach der Registrierung kann man direkt loslegen. Anzahl der gewünschten Spalten festlegen und Hintergrundfarbe definieren und los geht es.

Im ersten Versuch habe ich mich für ein 4 Spalten Layout entschieden – nach der Veröffentlichung war es mir aber doch zu doof und dann habe ich noch auf ein 3 Spalten Layout gewechselt. Alles kein Problem. Veröffentlichen geht nur einmal ab da wirken sich die Änderungen direkt aus. Also vor der ersten Veröffentlichung lieber 10 mal überlegen und Andere nach ihrer Meinung fragen. Nach der Veröffentlichung ist es wie bei einer Webseite, wenn der erste Eindruck schlecht ist, kommt niemand wieder. 

Inhalte erstellt man einfach als Blöcke welche man in den Spalten beliebig anordnen kann. Jeder Block ist von einer bestimmten Art zwischen denen man aber live wechseln kann. Der Inhalt der alten Art bleibt eine Weile erhalten. Falls die neue Art nichts ist wechselt man einfach zurück und hat nix an Inhalt verloren – sehr gut gelöst. Es werden folgende Arten angeboten:

  • Plain: Text oder Code
  • Lists: Ein bis Vier spaltige Listen, Bar Chart, Q&A Style
  • Media: Image/Photo oder Video (Video wird nicht ins PDF exportiert)
  • Live Content: URL zu einer dynamisch erzeugten Ressource im Netz
  • Column Break (erzeugt eine neue Spalte im PDF)
  • Page Break (erzeugt eine neue Seite im PDF)
Damit lies sich jeder meiner Wünsche erfüllen und so denke ich braucht es kein anderes Tool um mal schnell einen Spickzettel zu erstellen.

Anbei mein erstes Cheat Sheet für Apache-Karaf:




Einheitliche IDE erstellen


Flattr this

Motivation

Kennen Sie das auch? Sie haben gerade eine Open Source Software installiert, alles funktioniert einwandfrei und doch eine Kleinigkeit könnte angepasst werden. Ein Blick in die Quellen verrät Ihnen es ist ganz einfach und kein großer Aufwand. Sie starten ihre IDE laden die Sourcen herunter und … kämpfen mit nicht aufgelösten Abhängigkeiten. Ok, hier noch ein Plugin nachinstalliert und dort noch ein Plugin aktualisiert. Die meisten Probleme sind jetzt behoben aber ein oder zwei Probleme bleiben hartnäckig und es gelingt Ihnen erst nach intensiver Suche in Foren und im Web oder nach einer Kontaktaufnahme mit dem Projektgründer. Nach ein paar Tagen geben Sie auf und nutzen lieber eine andere Software. 

Oder Sie sind Mitglied in einem Entwickler Team und dürfen einen neuen Kollegen einarbeiten. Also zunächst einmal den Arbeitsplatz einrichten, eclipse aufsetzen und konfigurieren, Projekt auschecken und Server starten und … Mist irgendetwas läuft nicht. Das ging aber bisher immer und keiner hat damit Probleme! Ja klar seit dem letzten Zugang ist die Architektur oft geändert wurden aber das dürfte nicht diese Auswirkungen haben – es beginnt eine Fehlersuche welche manchmal Tage dauert und auf die Performance des Teams drückt. 

Im Eclipse Umfeld gab und gibt es Projekte welche sich dieses Thema’s annehmen. Als Beispiele seien hier die folgenden genannt:

Erste vollständige Lösung

Bis auf den untersten Eintrag erbrachten alle in obiger Liste aufgeführten Projekte nur Teillösungen. Kick your eclipse in the cloud ist das erste Projekt welches aus meiner Sicht eine vollständige Lösung zur Herstellung identischer Entwicklungsumgebungen bietet. Dabei wurde wirklich an alles gedacht. Zunächst wird im Web nach einem Baukasten System die gewünschte Eclipse zusammen geklickt. Dann wird das ganze Paket mit einem Namen versehen und zusammengeschnürt. Nach ca. 15 Minuten steht das Paket zum Download bereit. Das herunter geladene Paket kann plattformunabhängig gestartet werden (Window Vista und Lubuntu habe ich selbst ausprobiert). Es erscheint ein Installer welcher die lästigen Arbeiten übernimmt. Er erkennt auch wenn das Paket früher schon installiert wurde und stellt dann die Optionen: Aktualisieren, Reparieren, Löschen und Beenden bereit. Nach Durchführung der Installation steht eclipse in Ihrer Wunschkonfiguration zum Start bereit. Jetzt können noch weitere administrative Tasks durchgeführt werden. So können noch weitere Plugins installiert werden, Einstellungen in den Preferencen vorgenommen oder Projekte ausgescheckt und konfiguriert werden. Mit einem einfachen Klick lässt sich danach die in der Cloud liegende Konfiguration um die durchgeführten Tätigkeiten aktualisieren. Beim nächsten Download steht die Eclipse dann in der neuen Konfiguration bereit. Bestehende Installationen können über die Update Suche ebenfalls auf den aktuellen Konfigurationsstand gebracht werden. 

Teilen im Web

Die so erstellte Konfiguration kann dann per URL im Web verbreitet oder gezielt anderen Team Mitgliedern zur Verfügung gestellt werden. Dabei ist zu beachten, dass jeder den den URL besitzt ebenfalls das Recht besitzt die Konfiguration selbst zu ändern. Generell kann ein Passwort gesetzt werden. Dadurch wird die Installation nur für Personen die das Passwort kennen möglich. Allerdings hat jeder der eine Installation besitzt auch das Recht die Konfiguration in der Wolke zu ändern. Dies kann nach meinem Verständnis aktuell nur durchNutzung einer privaten Cloud geändert werden. 

Die eigene Wolke

Verständlicherweise werden Systemhäuser oder Behörden den oben beschriebenen Weg nicht einfach so nutzen können. Immerhin würden diese dann eine nicht gewollte Abhängigkeit zur Verfügbarkeit der Webseite erzeugen. Eine Nichtverfügbarkeit der Seite würde dann zu einem massiven Blocker im Kerngeschäft, ganz abgesehen von diversen Sicherheitsproblemen welche eine solche Online Lösung aufwirft. 

Für die Bedürfnisse des Goverments steht eine eigene Cloud Lösung zur Verfügung. Dazu ist ein Programm im Firmennetz zu installieren. Dieses stellt einen Server bereit welcher die einzelnen Eclipse Konfigurationen im Firmennetz bereitstellt. Um diesen Server zu Betreiben ist keine Online Verbindung zum Hersteller notwendig. Alles was auf dem Server passiert steht vollständig unter der Kontrolle des eigenen Firmennetzes. 

Während die Online Lösung kostenfrei ist, fallen für die eigene Wolke Lizenzgebühren an. Diese gestalten sich aus meiner Sicht jedoch recht moderat so das diese auch für Mittelstandsunternehmen interessant sein dürften – Preisliste.

Ausprobieren

Wer jetzt Lust bekommen hat seine eigene Konfiguration zu erstellen und einen Startpunkt sucht, kann sich gern versuchsweise meine Beispielkonfiguration installieren.


=-=-=-=-=
Powered by Blogilo

Eigene Bilder schützen


Flattr this

Motivation

Bei der Open Source Projektarbeit werden oft kleine Bildchen benötigt. Um keine Copyright Verletzungen zu begehen stelle ich mir diese selbst mit Gimp oder Blender her. Was mir dabei bislang noch nicht richtig gelang, ist eine Copyright Notiz im Bild zu hinterlegen. Der Bereich den Gimp dafür vorhält ist oft zu klein. Daher war ich auf der Suche nach Methoden wie ich Dateien mit Copyright Notiz ins Bild bekomme. Auf SemperVideo habe ich entsprechende Informationen gefunden.

Dateien verketten

Die einfachste Variante ist das anketten zusätzlicher Informationen. Dazu wird ganz simple der copy Befehl genutzt. Das Bild und seine Header Daten landen im Anfangsbereich. Die Zusatzinformation wird als Zip angehangen und landet im Ende Bereich. Bilddarstellungsprogramme lesen die Bildinfos auf Grund des Headers und Entpacker lesen die Pack Infos aus dem Ende Bereich. Damit können in einer scheinbaren Bilddatei die Bilddaten und die Zusatzdaten zeitgleich parallel existieren. Nachteil dieser Methode ist ganz klar, die Zusatzdaten lassen sich völlig unkompliziert wieder von den Bilddaten trennen. Daher ist diese Methode nur sinnvoll wenn das Bildformat kein einbetten von Dateien unterstützt.

Und so wird es unter Windows gemacht.

>copy /b image.jpeg +copyright.zip newimage.jpg

Quelle: Das Ganze habe ich aus folgendem SemperVideo indem es super erklärt wird.

Dateien einbetten

Zunächst müssen wir unsere Copyright Notiz (welche wieder als zip Archiv vorliegen sollte) mit uuencode „verschlüsseln“. Mit dem Exif Tool wird die Datei dann in den Kommentarbereich der Bilddatei eingeschleust.

>uuencode copyright.zip copyright.uue
>exiftool -Comment“<=“copyright.uue image.jpeg

Diese Info sollte solange erhalten bleiben bis jemand die EXIF Daten und dabei speziell den Kommentar verändert.

Quelle: Das Ganze habe ich aus folgendem SemperVideo indem es super erklärt wird.

Eclipse Committer werden


Flattr this

Motivation

Warum will man eigentlich Eclipse Committer werden? Da kann es mehrere Gründe geben:

  • Man will an einem Projekt welches unter Verwaltung der Eclipse Foundation steht mitarbeiten
  • Man hat an den Quellen eines Projektes der Eclipse Foundation lokal oder auf einem Fork Änderungen vorgenommen und möchte diese ins Hauptprojekt einbringen. Bei Verwendung von Git ein sogenannter Pull Request.
  • Weil es einfach Inn ist von sich behaupten zu können man entwickle an einem offiziellen Eclipse Projekt mit 😉

Jeder der von einem der obigen Motive angesprochen wird, möchte früher oder später auch seine Änderungen committen. Doch bevor er das darf muss die Eclipse Gemeinde ihm die Rechte dazu einräumen.

Auf Sourceforge.net war das letztlich oft das K.O. Kriterium weshalb viele Entwickler gar nicht erst versucht haben Kontakt mit dem Projektowner aufzunehmen. Die nervigen Aufnahme Rituals, oft mussten zunächst die Änderungen per tgz file für das Review per Mail versendet werden und ähnliches. Das alles nahm wesentlich mehr Zeit in Anspruch als die paar Kleinigkeiten einfach einzuarbeiten und das Projekt selbst auf der eigenen Homepage entsprechend den Lizenzvorgaben weiter zu hosten.

Dessen ist sich die Eclipse Foundation offensichtlich auch bewußt und hat ihren Prozess dahingehend optimiert und teilweise automatisiert. Doch die tausenden Wiki Seiten und hilfreichen Links zu allerlei Einsteiger Themen versperren oft den Blick auf die Links die wirklich notwendig sind.

Wie werde ich Committer in einem Eclipse Projekt?

Im Prinzip ganz einfach. In der Praxis müssen scheinbar 3 Dinge erfüllt sein:

  1. Man muss jemanden kennen der ein Interesse daran hat, das man aufgenommen wird.
  2. Jeder Commit muss mit einer Signed-by Zeile versehen werden
  3. Man muss die CLA gelesen, akzeptiert und rechtsverbindlich unter schrieben haben.

 

Punkt 1

Dieser ergibt sich meist von selbst indem man auf github ein interessantes Projekt der Eclipse Foundation (https://github.com/eclipse) oder eines Ihrer Mitglieder sucht und von diesem einen Fork erstellt. Auf diesem Fork – der ja nun der eigene ist – kann man alle Features seines Herzens einarbeiten und nach Fertigstellung einen Pull Request an den Projekt Owner stellen.

Punkt 2

Jeder Commit muss unterzeichnet werden. Dazu gibt es klare Vorgaben und am besten fährt man, wenn man in Eclipse folgende Einstellungen vornimmt:

Windows/Preferences/Team/Git

  • Commit Dialog: Insert Signed-off-by aktivieren
  • Configuration: In die Felder email und name die richtigen Werte eintragen (diese werden später beim Unterschreiben der CLA benötigt)

Punkt 3

  1. Die weiteren Schritte sind nur sinnvoll wenn Du die CLA akzeptieren willst.
  2. Registrieren unter: https://dev.eclipse.org/site_login/createaccount.php
    (mit dem Namen und der eMail aus den Signed-off-by Einstellungen)
  3. Unterschreiben der CLA unter https://projects.eclipse.org/user/login/sso

Das wars – ihr habt es geschafft.

Also dann viel Spaß beim Mitarbeiten:)

Eclipse konfigurieren


Flattr this

Motivation

Mit jeder neuen Eclipse Version die man installiert oder mit einem neuen Workspace fängt man wieder an die immer gleichen Einstellungen vorzunehmen, welche man für sich entdeckt hat. Das geht Ihnen vermutlich genauso wie mir. Von daher wollte ich mir einfach mal aufschreiben welche Einstellungen ich immer so vornehme und warum bzw. was ich daran als Vorteil oder Nachteil sehe.

Hat man seine Settings einmal festgelegt können diese übrigens über File/Export/Generell/Preferences exportiert bzw. über File/Import/Generell/Preferences auch wieder im neuen Workspace importiert werden. Wichtig ist aber, dass vor dem Import die entsprechenden Plugins installiert wurden.

Einstellungen unter Windows/Preferences

Diese Einstellungen wirken sich auf die installierten Plugin’s aus. Da die Plugins ihre Daten im .metadata Verzeichnis des aktuellen Workspace ablegen, sind sie im nächsten Workspace wieder neuzukonfigurieren.

Encoding

Generell/Workspace->Text file encoding auf UTF-8 setzen. Unterstützt die plattformübergreifende Arbeit inWindows und UnixUmgebungen.

Text Editoren

Generell/Editors/TextEditors

  • Show Print Margin aktivieren und auf 80 Zeichen setzen. Damit wirdbarrierefreies entwickelnunterstützt.
  • Show LineNumbersaktivieren.
  • Insert Spaces for tab aktivieren. Damit wird die plattformübergreifende Arbeit unterstützt. Deltas im SCM mit Unix undWinCommittern.

Git Support

Team/Git/CommitDialog

  • Insert Signed off by aktivieren. Manche Projekte z.B. die der Eclipse Foundation akzeptieren nurunterschriebeneCommits.
  • Include selected untracked files. Damit beim check in nixvergessenwird.

Team/Git/Configuration

  • email und name aktualisieren. Notwendig z.B. für Commits in offiziellen Eclipse Projekten.
    (in meinem Fall: funthomas424242@gmail.com und Thomas Schubert )

Code Style

Java/CodeStyle/Organize Imports

  • Number of static imports needed to .* auf 1 setzen. Das bringt den Vorteil das bei JUnit nicht immer assertEquals wieder zu Assert.assertEquals beim Organisieren der Imports gewandelt wird. Da man statische Imports ohnehin selten nutzen sollte kommt man gut damit zurecht.

Save Actions

Java/Editor/Save Actions

  • Perform selected action on save aktivieren. Dadurch werden beim Speichern bestimmte Schritte durchgeführt, die letztlich wenn es alle im Team aktiviert haben dazu führen, dass ein einheitlicher Kodestyle ganz von selbst entsteht. Somit gibt es in der Regel keine Differenzen im SCM nur Aufgrund unterschiedlicher Formattierungen. Vorraussetzungen sind natürlich die teamweite Nutzung der gleichen Formatierungsregeln.
  • Format source code / format all lines aktivieren. Nach dem Speichern sollte stets die ganze Datei formatiert werden. Geschützte Bereiche lassen sich dann immernoch mit //@formatter:off erzeugen und mit //@formatter:on die Formatierung im Kode wieder einschalten.
  • Organize imports aktivieren. Ganz wichtig die Importe sollten immer bereinigt werden. So werden ungenutzte Importe beim Speichern entfernt und die * Importe nach den gültigen Regeln aufgelöst.
  • Additional actions sollten auch aktiviert werden. Dadurch wird der Quellkode gesäubert. Einmalig initialisierte Variablen erhalten ein final, fehlende Override und Deprecation Annotationen werden ergänzt und unnötige Casts werden entfernt.

Einstellungen in den Projekteigenschaften

Diese Einstellungen hängen am Projekt und werden innerhalb des Projektes im .settings Ordner gespeichert. Sie funktionieren somit Workspace übergreifend, man muss nur das Projekt in denWorkspaceimportieren.

Auch diese Einstellungen lassen sich über File/Export/Generell/Preferences exportiert bzw. über File/Import/Generell/Preferences auch wieder im importierten.

 

Der Artikeln wird nach und nach ergänzt. Wer Tipps hat, bitte als Kommentar anfügen.

eGIT – eclipse plugin


Flattr this

Motivation

Statt ständig den Artikel über die Konfiguration der Eclipse Arbeitsumgebung anzupassen habe ich mich entschlossen lieber die von mir verwendeten oder evaluierten Plugins kurz zu beschreiben.

Heute habe ich ein Eclipse Plugin gesucht um ein Gitrepository auf Github einzubinden.

Zum Plugin

Das Plugin eGit Team Provider steht im Eclipse Marketplace zur Installation bereit. Es eignet sich hervorragend um ein Git Repository zu klonen und zu bearbeiten. Die Installation läuft wie bei Eclipse üblich – nach einem Neustart der IDE steht die neue Team Perspektive zu Verfügung. Man kann damit im Prinzip genauso wie vorher mit der CVS oder der SVN Perspektive arbeiten.

Wünschenswert

Das Plugin verfügt leider über keine Revert Funktion. Das ist für Umsteiger von SVN durchaus gewöhnungsbedürftig. Daher habe ich mir auf meinem lokalen PC noch TortoiseGit und das Git mit GitGUI und GitBash installiert. In der Kombination lässt es sich prima arbeiten. Was in Eclipse nicht geht wird mit TortoiseGit erledigt und eine Shell habe ich parallel auch offen um ab und an ein git status abzusetzen.

Markdown Text Editor – eclipse plugin


Flattr this

Motivation

Statt ständig den Artikel über die Konfiguration der Eclipse Arbeitsumgebung anzupassen habe ich mich entschlossen lieber die von mir verwendeten oder evaluierten Plugins kurz zu beschreiben.

Nachdem die letzte Suche ein Plugin brachte welches nicht ganz meine Ansprüchen genügte habe ich heute nun ein Plugin gefunden welches sowohl eine gute Preview einer Markdown datei im Editorbereich leistet wie auch noch einen einfachen Editor bereitstellt.

Zum Plugin

Das Plugin lässt sich generell im Marketplace der Eclipse „Kepler“ finden und zwar unter „Markdown Text Editor“. Allerdings ist es von dort nicht installierbar. Über „more Info“ gelangt man auf die Projektseite und dort findet man den eigentlichen URL für den Eclipse Update Site Manager:

http://winterstein.me.uk/projects/tt-update-site/

Diesen also für die Installation im Update Site Manager eingeben und schon kurz darauf ist das Plugin installiert.

Wenn wir nach dem obligatorischen Neustart der Eclipse ein md File öffnen wird automatisch schon der neue Markdown Editor benutzt. Allerdings sieht er auf den ersten Blick nicht anders aus als ein Texteditor und laut Beschreibung hat er auch nicht viel mehr Feature (allerdings soll er falten und ähnliches unterstützen).

Letztlich finden wir auch eine neue Markdown View. In dieser können wir die Preview eines md Files betrachten. Die View lässt sich mit etwas motorischem Geschick auch im Editor Panel als Tab anbringen.

Somit ist alles gut und wir haben das Plugin gefunden mit dem wir zukünftig unsere Markdown Dateien für Github bearbeiten.

GitHub Flavored Markdown Viewer – eclipse plugin


Flattr this

Motivation

Statt ständig den Artikel über die Konfiguration der Eclipse Arbeitsumgebung anzupassen habe ich mich entschlossen lieber die von mir verwendeten oder evaluierten Plugins kurz zu beschreiben.

Heute habe ich ein Eclipse Plugin gesucht um eine Datei im Markdown Format bereits am Rechner im endgültigen Layout sehen zu können. Bislang musste ich die Datei immer erst auf Github hochladen um das Ergebnis zu sehen. Aber diese kleinen, einzelnen Commits machen natürlich keinen Sinn. Daher einfach einen Viewer installiert.

Zum Plugin

Das Plugin „GitHub Flavored Markdown viewer plugin (update site)“ lässt sich einfach über den Marketplace in der Eclipse „Kepler“ installieren. Nach dem obligatorischen Neustart der Eclipse sucht man bei der Selektion eines *.md Files allerdings vergeblich im OpenWith nach einen neuen Eintrag.

Zunächst muss man unter Windows/Preferences/GFMViewer seine Login Daten für Github eintragen. Anschließend kann man jedes *.md auch über den Eintrag „Show in GFM view“ im Kontextmenü öffnen. Jetzt wird das Markdown File tatsächlich frisch gerendert dargestellt.

Allerdings merkt man gleich, dass es sich um keinen Editor handelt denn das Panel lässt sich nicht in an die Stelle des Editors platzieren. Jetzt kann man sich für eine waagerechte oder senkrechte Teilung entscheiden aber letztlich ist beides schlecht. Als Tab im Editorbereich lässt es sich einfach nicht einfügen und so bleibt nicht mehr viel Platz für den eigentlichen Editor.

Ergo wenn man die View braucht – öffnen und danach sofort wieder schließen.

Was lernen wir daraus? Eigentlich suchen wir ein Editor Plugin welches (wie der Plugin Wizard) eine Tab für die Darstellung des Kodes und eine für die Preview Ansicht besitzt.

Github – Pull Requests aktuell halten


Flattr this

Motivation

Auf Github kann jeder Nutzer auf einfachster Weise einen Fork von seinem Lieblingsprogramm erstellen und nach Lust und Laune auf diesem die gewünschten Features selbst implementieren. Sind diese fertiggestellt werden sie als Pull Request an den eigentlichen Projektowner gesendet.

In der Regel war dieser aber auch nicht untätig und hat sein Projekt auch weiterentwickelt. Oder er ist gerade mitten in der Entwicklung eines neuen Features und so bleibt der Pull Request eine ganze Weile liegen. In der Zeit häufen sich die Commits des Projektowners und der Stand auf dem der Pull Request basiert ist hoffnunglos veraltet.

Jetzt erst sieht der Projektowner den Pull Request und versucht in zu integrieren – doch leider hat sich das Projekt soweit weiter entwickelt, dass viele Versionskonflikte auftreten. Das möchte sich der Owner nicht antuen und fordert vom Ersteller des Pull Requests das er diesen bitte zunächst mit dem aktuellen Versionsstand abgleicht. Doch wie geht das? Genau das soll hier kurz beschrieben werden.

Vorraussetzungen

Bevor man einen Pull Request auf Github stellen kann, hat man in der Regel das Original Repository auf Github geforkt und davon einen Klone auf seinen lokalen Rechner gezogen.

Will man nun ein neues Feature implementieren sollte unbedingt ein neuer Branch für die Entwicklung des Features abgespalten werden. Dies hat den Vorteil, das man zeitgleich an verschiedenen neuen Features arbeiten kann ohne von der Fertigstellung oder der erfolgreichen Integration eines Features abhängig zu sein. Außerdem hält man sich so auch den master für eine stets lauffähige aktuelle Version frei. Letzteres ist gut, da es immer wieder mal Situationen gibt in denen man die gerade implementierte Lösung nach Fehlern durchsucht und dann ein Vergleich mit einer aktuellen, lauffähigen Version sehr hilfreich sein kann. Generell gilt aber auch auf Github pro Branch ist nur ein Pull Request möglich.

Aktualisierung des Branches

Die Lösung besteht im Prinzip darin bei der Entwicklung möglichst frühzeitig die neuen Änderungen des Owners in den eigenen featurebranch zu integrieren. Hierzu erzeugen wir uns einen Alias upstream im lokalen Git Repository.

(alles in eine Zeile schreiben, der Browser zeigt hier gern 2 Zeilen an)

git remote add –track master upstream git://github.com/owner/projectname.git

evtl. reicht auch die einfachere Variante

git remote add upstream git://github.com/owner/projectname.git

Als Werte für owner und projectname werden die Angaben des originalen Repositories verwendet von dem wir selbst unseren fork gezogen haben. Damit steht uns ein Alias für den Fetch bereit und diesen nutzen wir auch gleich. Wir befinden uns also aktuell im lokalen Projektverzeichnis und arbeiten auf dem Branch (also der Branch ist lokal ausgecheckt und in der Regel von uns auch schon editiert). Jetzt holen wir uns die Neuigkeiten vom Original Repository:

git fetch upstream

Wenn das funktioniert hat und das sollte immer funktionieren oder ihr habt Euch vorhin verschrieben oder das Internet ausgeschaltet, dann mergen wir die Neuigkeiten in unseren lokalen branch mit:

git merge upstream/master

oder die Variante ohne Auto Commit

git merge upstream/master –no-commit –no-ff

So jetzt noch ein bischen Konflikte lösen 😉 committen und falls nötig den Pull Request aktualisieren bzw. bitte auch dokumentieren. Kommunikation ist alles und hilft dem Projektowner bei der Bewertung und Einarbeitung Eures Pull Requests.

Also Happy Pulling 🙂

Und falls doch mal was schief geht und der ganze Branch zurück auf „Null“ – dem Stand des originalen Repositories – gebracht werden soll? Dann sollten diese Befehle helfen

git remote add upstream git://github.com/wp-cli/wp-cli.git (nur wenn wir den alias oben nicht schon angelegt haben)
git fetch upstream
git branch backup
git reset –hard upstream/master
git push –force

Damit habt ihr den aktuellen Branch zurück gesetzt.

Bei neueren Git Versionen scheint das Rücksetzen auf den upstream (er muss schon mit git remote add gesetzt wurden sein) wie folgt zu funktionieren:

git rebase –onto upstream/master

Diese Variante würde ich immer vorziehen, weil damit auch bereits veröffentlichte Dinge bearbeitet werden können.

 

Für Hinweise, Tipps, Anmerkungen und Kommentare bin ich stets dankbar.

 

Quellen:

http://gun.io/blog/how-to-github-fork-branch-and-pull-request/

http://scribu.net/blog/resetting-your-github-fork.html

http://www.senaeh.de/git-prinzip-beispiele/