Tag Archives: eclipse-plugin

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.

Advertisements

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.