Wenn man in seinem Github Fork Änderungen aus dem Original nachziehen will kann es unter speziellen Umständen Änderungen geben die sich nicht per Weboberfläche und one-click hinzufügen lassen. Diese sind auf der Oberfläche rot markiert und mit “Will likely not apply cleanly” gekennzeichnet. Um dennoch auf einen ensprechenden Stand zu kommen muss man in der Kommandozeile Hand anlegen:
Erst die eigenen Änderungen rückgängig machen durch zB einen frischen Checkout.
Anlässlich der millionsten Installation eines Plugins über den Eclipse Marketplace seit Juni 2010 wollte ich hier ein wenig über die Top10 der gedownloadeten Plugins schreiben, sowie über die von mir eingesetzten Erweiterungen.
01. Subclipse
Subclipse steht in Konkurrenz zu Subversive, welches ich verwende. Auch wenn ich Subclipse schon selbst verwendet habe, bin ich doch überzeugter Subversive Nutzer. Wohl aber nur weil ich das Teil bereits gewöhnt bin. http://marketplace.eclipse.org/content/subclipse
02. Maven Integration for Eclipse
Unverzichtbar für jedes Maven Projekt. Da ich selbst bei TrayRSS auf Maven setze komme auch ich nicht um m2e herum. Hier bleibt zu resumieren, dass einem das Plugin nicht davor bewahrt sich mit Maven selbst auseinander zu setzen, um das beste für seinen Build zu erzielen. Wer sich mehr mit Maven auseinandersetzen möchte, dem empfehle ich die Dokumentation auf der Maven Seite selbst: http://maven.apache.org/ Diese ist mMn gut aufbereitet. Für tiefersitzende Probleme ist vielleicht folgendes frei erhältliches EBook hilfreich: The Maven Cookbook. Es ist als PDF oder als HTML Version als direktes Nachschlagewerk vorfügbar. http://marketplace.eclipse.org/content/maven-integration-eclipse
03. Subversive – SVN Team Provider
Das SVN Plugin meiner Wahl. Bisher durchaus ein Usabilitygraus in der Installation, hat der Market die Installation des Plugins erheblich vereinfacht. Subversive bietet nämlich die Möglichkeit über verschiedene Connectoren auf die Repositories zuzugreifen. Diese mussten aus lizenzrechtlichen Gründen über eine extra Installationsseite nachinstalliert werden. Der Market bietet nun nach Installation des Basis-Plugins eine eigene Auswahlseite auf der die gewünschten Connectoren gewählt werden können, sodass Eclipse diese dann ohne weiteres zutun des Benutzers installiert. http://marketplace.eclipse.org/content/subversive-svn-team-provider
04. EGit – Git Team Provider
“Neu” in der Familie der meiner Plugins ist EGit. Da ich Git noch nicht sehr lange als Versionierungsverwaltung nutze, und erst langsam auf den Geschmack von Git und Github gekommen bin, beschränkt sich meine Erfahrung mit dem Plugin auf ein paar Feldversuche. Git selbst hat mich bereits überzeugt. Und in Zusammenhang mit Open Source finde ich hat Git alle Trümpfe in der Hand. Das Plugin selbst ist etwas komplexer aufgebaut, lässt aber auf den ersten Blick nichts missen. Als Unterstützung für Git-Einsteiger ist es jedoch im Gegensatz zu den SVN-Plugins meiner Meinung nach nicht geeignet. Hier führt der Weg an einem Kommandozeilenbasierten Einstieg nicht vorbei. http://marketplace.eclipse.org/content/egit-git-team-provider
05. Spring IDE
Dieses Plugin habe ich bisher noch nicht genutzt. Equivalent dazu sind wohl die JBoss Tools. Um Spring Anwendungen zu entwickeln greife ich selbst noch auf die Pluginsammlung von MyEclipse zurück (u.a. die MyEclipse Spring Tools), welche von meinem Arbeitgeber zur Verfügung gestellt wurde. http://marketplace.eclipse.org/content/spring-ide
06. Eclipse Color Theme
Dieses Plugin nutze ich ebenfalls nicht. Ich habe mir im Zuge dieses Artikels die Funktionsweise des Plugins angesehen, denke aber dass ich es weiterhin nicht einsetzen werde. Ich war bisher noch nie der Typ Mensch, der seine Fenster farblich komplett neu coloriert und muss daher auch den Inhalt des Editors an nichts anpassen. http://marketplace.eclipse.org/content/eclipse-color-theme/metrics
07. PyDev – Python IDE for Eclipse
Jeder der schon mal in Eclipse eine Python Anwendung entwickelt hat kommt an diesem Plugin eigentlich nicht vorbei. Auch ich nicht. Ich habe damit z.B. Pong programmiert. Mag es zum Python Entwickeln nicht mehr missen, auch wenn die mit Python mitgelieferte IDLE Entwicklungsumgebung durchaus auch seinen Charm und seine Einsatzzwecke hat. http://marketplace.eclipse.org/content/pydev-python-ide-eclipse
08. FindBugs Eclipse Plugin
Dieses Plugin habe ich aktuell ebenfalls nicht im Einsatz. Das sollte ich allerdings nochmal gründlich überdenken. Erste Versuche damit vor mehr als einem Jahr waren eigentlich ein für meinen Code interessant Erlebnis. FindBugs versucht mittels prüfen auf Bug Pattern Fehlerquellen im Code zu identifizieren durch z.B. falsch genutzte API Aufrufe. Vielleicht gebe ich dem Plugin bald mal wieder einen Versuch. http://marketplace.eclipse.org/content/findbugs-eclipse-plugin
Als ich damals für eine Übung an der TU mit JBoss Seam entwickeln musste hab eich die JBoss Tools kennen gelernt. Sie sind eine mächtige Sammlung an Tools für das Entwickeln von Webanwendungen. Dabei habe ich aber auch ein paar Grenzen kennengelernt. So erzeugen die JBoss Tools in Fundament gegossene Projektstrukturen, was einem späteren Einsatz der Tools auf bereits vorhandene Projekte etwas erschwert. Dennoch bieten sie genug positive Funktionalitäten um derartige Hürden zu überwinden. Und sie sind natürlich perfekt auf den JBoss Server zugeschnitten ;) http://marketplace.eclipse.org/content/jboss-tools-1
Aus den Top10 habe ich somit bereits 8 Verwendet und verwende 6 immer noch, lediglich 4 weitere Plugins kommen bei mir bewusst zum Einsatz:
Leider ist der Eclipse Marketplace noch nicht für Eclipse 4.x vorhanden. Auf diese Version bin ich im Zuge des Releases von Java 7 umgestiegen. Wenn jedoch der große Umstieg bevorsteht hoffe ich ihn auch darin wieder nutzen zu können.
Die letzten Wochen habe ich euch Git näher gebracht und euch gezeigt wie ihr euch einen eigenen Git-Server aufsetzen könnt. Jetzt wollen wir noch Kapital daraus schlagen und Git mit einem Bugtracker verbinden. Ich nutze nun schon seit längerem MantisBT http://www.mantisbt.org welcher mithilfe von ein paar Plugins an Git angebunden werden kann. Dies ermöglicht es einem anhand von Commit Messages Tickets in MantisBT zu steuern und zB ein offenes Ticket zu schließen.
Das Plugin trägt den klingenden Namen Source Control Integration und wurde von John Reese geschrieben. MantisBT selbst setzt das Plugin ein und vermutlich nutzen sie dort auch die Git Variante seit dem Umstieg des Bugtrackers auf Github. Das Plugin selbst besteht aus einem Framework und verschiedene Module für diverse Web-SourceControl Derivate wie z.B. Gitweb, Github, WebSVN. Eine Anleitung wie man dieses Plugin installiert findet sich ebenfalls im Blog von John Reese.
Ich will meine Schritte bei der Installation hier auf Deutsch zur Ergänzung meiner Git Artikel ebenfalls erfassen.
Als erstes galt es das Plugin und seine Abhängigkeiten zu organisieren: Meta Programming und Source Control Integration die entprechenden Repos wurden natürlich per Git geladen und jeweils ins Mantis Plugin Verzeichnis geladen. Im Backend von Mantis konnten diese dann aktiviert werden. Die richtige Reihenfolge konnte ob entsprechend optisch hervorgehobener Abhängigkeiten nicht versemmelt werden.
Nun hat man einen neuen Hauptmenüpunkt: Repositories
In diesem gilt es nun einen Verweis auf sein GitRepository zu erstellen. Name und Typ ausgewählt und schon gehts über den Create Repository Button weiter
MantisBT Sourceintegration Create Repository
Auf der zweiten Seite muss man nun die Daten zum zu überwachenden Repository eintragen
MantisBT Sourceintegration Repository Details
Hierbei wird die URL die auf das Gitwebverzeichnis verweist erst als ganzes eingetragen und dann in Root und Projektteil aufgesplittet. Noch den Master Branch als zu überwachender Branch definiert und schon kanns losgehen. Mit einem klick auf das Repository und dann den Button “Import Latest Data” kann die erfolgreiche Verbindung auch gleich ausgetestet werden.
Der Author empfielt nun einen Cronjob zB per curl einzurichten damit dieser Prozess automatisiert wird. Die ID ist über Mantisbt rauszufinden (Einfach die URL die Mantis nutzt anschaun)
Dabei bekomme ich leider eine Fehlermeldung die auf einen ungültigen Sicherheitstoken verweist. In einem Blog Eintrag von Chris Dornfeld habe ich jedoch einen angepassten URL Aufruf dazu gefunden, der nicht auf ein Repository eingeschränkt ist und den Import per Cronjob ermöglicht:
Fertig aufgesetzt habe ich nun doch etwas Zeit gewonnen, die ich nun ins Projekt statt ins Projektmanagement stecken kann.
Sollten bei euch noch andere Probleme auftreten, möchte ich noch auf eine kleine Hilfestellung im Blog des Authors verweisen, vielleicht werdet ihr ja dort fündig.
Nachdem ich hier erst letztens aufgezeigt habe wie man seinen eigenen Git Server mithilfe von Gitosis aufsetzt, möchte ich heute noch etwas tiefer in die Materie vordingen. Heute soll der Git Server visualisiert werden mithilfe von Gitweb.
Gitweb
Im Prinzip ist Gitweb recht flott installiert wenn man auf die Paketverwaltung der Distribution seines Vertrauens setzt. In meinem Beispielfall ist das Debian und mittels
$ aptitude install gitweb
wird die Software installiert. Damit Gitweb auf die eigenen Repositories zugreifen kann muss natürlich die Konfiguration /etc/gitweb.conf angepasst werden:
# path to git projects (.git) - hier auf das bei der installation von gitosis eventuell angepasste Verzeichnis linken
$projectroot = “/home/git/repositories/”;
# directory to use for temp files
$git_temp = “/tmp”;
# target of the home link on top of all pages
#$home_link = $my_uri || “/”;
# html text to include at home page
$home_text = “indextext.html”;
# file with project list; by default, simply scan the projectroot dir.
# $projects_list = $projectroot;
# Point to projects.list file generated by gitosis. - Hier ist wieder ein anpassung erforderlich wenn das homeverzeichnis wie bei unserem Beispiel angepasst wurde
$projects_list = “/home/git/gitosis/projects.list”;
# stylesheet to use
$stylesheet = “/gitweb.css”;
# javascrip code for gitweb
$javascript = "gitweb.js";
# logo to use
$logo = “/git-logo.png”;
# the ‘favicon’
$favicon = “/git-favicon.png”;
# A list of base urls where all the repositories can be cloned from.
# Easier than having per-repository cloneurl files.
@git_base_url_list = (’git://git.host.example’);
#$strict_export = “true”;
$projectroot – der Pfad zu den von gitosis erzeugten Repositories, in unserem fall /home/git/repositories; $projects_list – damit wird gitweb gezeigt welche Repos vorhanden sind, entweder indem man auf das root Verzeichnis verweist oder auf eine Datei die eine Liste der Repositories beinhaltet. Verweist man auf die von gitosis erzeugte Projektliste “/home/git/gitosis/projects.list”; kann man über die Konfiguration von gitosis gezielt steuern, welche Repos angezeigt werden sollen.
Projekte die nicht angezeigt werden können mit obiger Konfiguration trotzdem noch durch direkten Aufruf über die Adressliste des Browsers erreicht werden. Soll auch dieser Aufruf unterbunden werden muss man den strict_export parameter auf true setzen, einfach dazu das Kommentarzeichen entfernen.
Nun muss noch im Webserver, in meinem Falle Apache2, richtig konfiguriert werden. Dazu habe ich eine eigene virtuelle Domain eingepflegt in folgender Datei /etc/apache2/sites-available/gitweb:
<VirtualHost *:80>
ServerAdmin john@example.com
DocumentRoot /var/cache/git
ServerName git.example.com
Alias /gitweb.css /usr/share/gitweb/gitweb.css
Alias /git-favicon.png /usr/share/gitweb/git-favicon.png
Alias /git-logo.png /usr/share/gitweb/git-logo.png
ScriptAlias / /usr/lib/cgi-bin/gitweb.cgi
</VirtualHost>
Abschließend muss noch der Benutzer des Webservers www-data der gitosis gruppe hinzugefügt werden, damit der lesende Zugriff erfolgen kann. Danach wird die neu erstellte Subdomain noch aktiviert
$ a2ensite gitweb
Und Apache neu gestartet
$ /etc/init.d/apache2 reload
Wer cgi noch enabeln muss sollte danach nicht vergessen Apache ganz neu zu starten
$ /etc/init.d/apache2 restart
Und schon sollte der eigene Gitweb Zugriff fertig aufgesetzt sein.
Gitweb in der Gitosisconf
Fehlt natürlich noch die Konfiguration der Repositories um einzelne Projekte in Gitweb auszublenden
Im allgemeinen Bereich definiert hier der vorsichtige User folgendes:
[gitosis]
daemon = no
gitweb = no
Damit schließt man prinzipiell alle Projekte von der Ansicht in Gitweb aus. So wechselt man von einem Opt-Out Verfahren bei dem bei jedem Repo angegeben hätte werden müssen dass es nicht angezeigt werden soll, zu einem Opt-In, bei dem man sich bewusst für das anzeigen in Gitweb entscheiden muss.
Will man nun zB das Repository test in Github angeboten bekommen ist folgender Eintrag notwendig:
[repo test]
description = A repository where tests can take place
owner = testuser
daemon = no
gitweb = yes
Will man seinen Gitosis – Gitserver etwas öffentlicher gestalten und der Allgemeinheit lesenden Zugriff auf seine Repositories gewähren will, dem steht das git Protokoll zur Auswahl. Der entsprechende Daemon ist unter Debian denkbar leicht zu installieren
$ aptitude install git-daemon-run
Der Git Daemon verwendet jedoch nicht die üblichen /etc/init.de/ Runscripte sondern nutzt runit/runsv. Ein entsprechender Symlink hilft da alten Gewohnheiten schnell mal auf die Sprünge:
$ ln -s /usr/bin/sv /etc/init.d/git-daemon
Abschließend noch die Konfiguration /etc/sv/git-daemon/run an die Pfade von Gitosis angepasst (Hier als Beispiel mit dem angepassten Home Verzeichnis aus dem dazugehörigen Gitosis Tutorial):
