Vielfalt oder Uniform? Eclipse und IntelliJ im selben Projekt

Wenn wir mit neuer Besetzung in ein Projekt starten, stellen sich viele Fragen: welche Sprachen werden verwendet? Wie soll die Pipeline aussehen? Welche Tools verwenden wir?

Für die meisten Punkte findet sich schnell eine gemeinsame Lösung. Oft hat sich bereits ein Vorgehen oder Muster etabliert und kann so wiederverwendet werden – zum Beispiel beim Thema Codeformatierung. Doch mit unterschiedlichen Menschen kommen auch unterschiedliche Vorlieben. Viele Entwickler gewöhnen sich über lange Zeit an eine IDE und kennen sich damit sehr gut aus. Das Problem ist nur, dass selten alle die gleiche Entwicklungsumgebung nutzen möchten und hier muss eine Entscheidung getroffen werden – setzen alle das gleiche Werkzeug ein oder bleibt jeder bei dem, was er kennt? Hier ein paar Argumente für beide Seiten. (Hinweis: ich gehe hier nur auf die beiden verbreitetsten IDEs Eclipse und IntelliJ ein, die bei uns im Java-Umfeld Relevanz haben.)

Eine IDE für alle

Die einfachste Möglichkeit ist es, eine IDE als Standard festzulegen, die alle im Team dann nutzen (müssen). Daraus ergeben sich folgende Vorteile:

  • Alle Einstellungen, von Codeformatierung über Templates bis zu Save Actions, müssen nur an einer Stelle gepflegt werden. Dazu kann man noch je nach IDE bequeme Verteilungsmechanismen nutzen, z.B. Oomph oder Yatta bei Eclipse oder das Settings Repository bei IntelliJ.
  • Tiefergehendes Know-How im Umgang mit der Entwicklungsumgebung kann sich gut im Team verteilen – es gibt keine fragenden Gesichter, wenn jemand ein Feature erklärt, sondern eher den „Aha-Effekt“.
  • Jeder findet sich beim Anderen zurecht – das hilft gerade bei Pair Programming Sessions. So vermeidet man den Klassiker: „Welche Tastenkombination ist das denn hier?“

 

Gemischte Welt

Der Gegenentwurf: jeder arbeitet mit dem, was er kennt und liebt. Da kommt folgendes in den Sinn:

  • Wer sich nicht umstellen muss, kann effizient arbeiten. Bis die ganzen Menüwege, Tastenkürzel und Verhaltensweisen einer neuen IDE in Fleisch und Blut übergegangen sind, vergeht viel Zeit und die ist ja bekanntermaßen Geld. Hier gilt es also dringend abzuwägen, ob der erhöhte Abstimmungsaufwand bei gemischten IDEs das rechtfertigt.
  • Es entsteht ein Know-How Austausch über den eigenen Tellerrand hinweg. Je nach Anwendungsfall bieten verschiedene Werkzeuge objektiv betrachtet eine bessere Unterstützung und da ist es gut, wenn man weiß, welches das richtige Werkzeug ist. Nicht umsonst gibt es das Sprichwort: „Wer nur einen Hammer hat, sieht in jedem Problem einen Nagel.“

 

Möglichkeiten zur Zusammenarbeit

Für beide Vorgehensweisen gibt es gute Gründe. In einem aktuellen Projekt haben wir den zweiten Weg gewählt und sind nach anfänglichen Startschwierigkeiten inzwischen ganz zufrieden. Wie bekommt man aber nun eine Zusammenarbeit einfach hin?

Doppelte Pflege

Die schlechteste Variante – jede Einstellung separat für die IDEs festlegen und pflegen. Die Abweichung voneinander ist quasi vorprogrammiert und man ärgert sich schnell über riesige Diffs im Pull Request.

EditorConfig

Das Projekt editorconfig.org hilft dabei, grundlegende Konventionen für den Code IDE-übergreifend einhalten zu können. Es wird von sehr vielen Editoren unterstützt (teils über Plugins, teils nativ) und bietet eine Konfiguration über .ini Dateien nach folgendem Muster:

Solange die gemeinsamen Regeln für den Code im Team nicht zu umfangreich sind, ist das eine tolle Sache. Sobald die Regeln aber über die unterstützten Features hinausgehen, scheitert der Ansatz leider.

Eclipse Settings in IntelliJ importieren

IntelliJ unterstützt seit Version 13 von Haus aus den Import von Eclipse Formatierungseinstellungen. Leider gab es hier recht schnell Ernüchterung bei uns, denn immer wieder fanden wir einzelne Punkte, die dann doch nicht übernommen wurden. Als Alternative nutzen wir inzwischen die beiden IntelliJ Plugins Eclipse Code Formatter und Save Actions. Dadurch konnten wir tatsächlich (fast!) alle unsere Regeln durch einen einfachen Import übernehmen. Eine 100% Lösung haben wir zwar immer noch nicht, aber dieser Weg funktioniert für uns ausreichend gut. Die festgelegten Regeln ändern sich ja im Laufe des Projekts eher wenig, daher ist uns vor allem wichtig, dass neue Entwickler sich schnell einrichten können.

 

Würde ich es im nächsten Projekt nun genauso tun? Ganz klar: es kommt drauf an – und zwar auf die Teammitglieder. Wenn es eine halbwegs gleiche Verteilung an Präferenzen gibt, dann ist das Mischmodell ein guter Weg, um früh effizient arbeiten zu können und die Erfahrung hat gezeigt, dass es funktioniert. Bei einem homogeneren Team mit wenigen Ausreißern würde ich wohl eine IDE vorgeben, um die dadurch entstehenden Vorteile für das Projekt mitnehmen zu können.

OpenShift Deployment mit dem fabric8-maven-plugin

Das Thema DevOps ist allgegenwärtig und viele Entwicklerteams sehen sich mit der Tatsache konfrontiert, dass sie ihre Anwendungen nicht nur bauen, sondern auch selbst betreiben müssen. Äußerst beliebt ist dabei derzeit natürlich Kubernetes oder auch OpenShift als Plattform. Doch die händische Pflege von Deploymentkonfigurationen kann mühsam sein. Hier kommt fabric8 ins Spiel: mit dem fabric8-maven-plugin lässt sich das Deployment nahtlos in den Buildprozess integrieren.

Sinnvolle Basiswerte werden durch die bereits bestehenden Einstellungen aus der POM ergänzt und können bei Bedarf gezielt überschrieben werden. Aber auch schon vor dem Deployment hilft das Plugin, denn es unterstützt auch bei der Erstellung eines Docker-Images. Je nach Umgebung ist es aber bei OpenShift nicht möglich, direkt mit Docker zu kommunizieren. Stattdessen gibt es hier die Variante des Source2Image Builds, welcher ebenfalls von fabric8 unterstützt wird.

Da die Dokumentation (https://maven.fabric8.io/) nicht unbedingt den leichtesten Einstieg bietet, gibt es hier eine kleine Hilfestellung.

Vorbereitung

Zuerst binden wir das Plugin ein:

Jetzt greift bereits der „Zero-Config“ Modus von fabric8. Mit den Voreinstellungen erarbeitet das Plugin selbstständig einen Plan für das zu bauende Image. Rufen wir also nun mvn package fabric8:build auf, wird unser Jarfile mit dem fabric8-Basisimage zu einem Dockerimage gebaut. Da wir aber davon ausgehen, keinen Zugriff auf Docker zu haben, müssen wir die erste Konfiguration vornehmen:


Image bauen

Mit diesen Properties wechselt fabric8 in den OpenShift-Modus. Diesmal führt der Aufruf von mvn package fabric8:build zu einem OpenShift Binary Build. Das bedingt, dass die OC Tools installiert und mit dem Zielcluster verbunden sind. Ist der Buildvorgang erfolgreich, dann existiert nun ein ImageStream mit der artifactId im gewählten Namespace (dieser lässt sich mit auch mit -Dfabric8.namespace beim Aufruf ändern). Als Basisimage wird bei der S2I-Strategy standardmäßig fabric8/s2i-java:latest verwendet. Möchte man das ändern, lässt sich das in der Pluginkonfiguration bewerkstelligen:


Deployment

Im nächsten Schritt kümmern wir uns um die Deploymentkonfiguration. Mit mvn fabric8:resource generiert uns das Plugin eine Reihe von YAML Dateien unter target/classes/META-INF/fabric8/openshift für das Deployment, den Service und die externe Route.

Auch wenn viele der hinterlegten Werte eine gute Ausgangsbasis sind, wollen wir doch meistens die ein oder andere Anpassung vornehmen. Bei uns hat sich im Realfall die Kombination aus einzelnen Definitionen in einer YAML-Datei und dem maven-resources-plugin bewährt. Dabei legen wir beispielsweise folgende Anpassungen fest (unter src/main/fabric8/deployment.yaml):

Wir wollen also das Speicherlimit des Containers festlegen. Dank des maven-resources-plugin können wir dafür dann eigene Properties oder auch die bereits vorhandenen (wie z.B. artifactId) verwenden. Das schaffen wir mit folgender Anpassung der POM:

Fabric8 fügt dann unsere konkreten Einstellungen und die Standardkonfiguration zum Endergebnis zusammen. Auf diese Weise lässt sich gezielt nach gewohntem Muster alles so konfigurieren, wie man möchte. Alternativ dazu bietet das Plugin auch viele Konfigurationsmöglichkeiten über die POM direkt an; dies stellte sich bei uns jedoch als zu unübersichtlich heraus.

Zu guter Letzt können wir nun mit mvn fabric8:apply die erstellten Ressourcen im Cluster anwenden und damit unsere Anwendung deployen.

Ausblick

Dank des Plugins lässt sich der Deploymentvorgang schnell vereinfachen. Wir kratzen dabei jedoch nur an der Oberfläche – fabric8 bietet noch sehr viel mehr. Wird die eigene Anwendung beispielsweise mit Spring bzw. Spring Boot entwickelt, erkennt fabric8 dies und passt die Konfiguration entsprechend an – inklusive Healthchecks für Spring Boot Actuator. Der klassische Weg mit dem Docker Daemon funktioniert natürlich auch und über mvn fabric8:watch bietet das Plugin sogar ein automatisches Redeployment bei Änderungen im Workspace.

Wer nun Interesse gefunden hat, dem sei trotz des etwas holprigen Einstiegs die ausführliche Dokumentation ans Herz gelegt, ergänzt durch das Handbuch des docker-maven-plugin, welches in das fabric8-maven-plugin integriert ist. Hier lassen sich manchmal ein paar ergänzende Informationen finden.

Tutorial: Datenbankanbindung mit EclipseLink unter Apache Karaf

©-t_kimura---istockphoto.com_blogMöchte man eine OSGi Anwendung betreiben, ist dazu erstmal nicht viel nötig: Die gewünschte Implementierung nehmen, eigene Bundles deployen und schon kann es losgehen. Wächst mit der Zeit die eigene Software, steigen aber auch die Anforderungen an die Laufzeitumgebung. Mit Karaf bietet das Apache Projekt eine kompakte Plattform zum Betrieb von OSGi Anwendungen, welche sich durch ein reichhaltiges Plugin-Angebot (sog. Features) erweitern lässt.

Mehr

Links zu den 12 besten Onlinetools um Webseiten zu testen

Wer heutzutage Webseiten erstellt, begegnet unzähligen Hürden. Hat man sich durch Bücher oder Tutorials über HTML, CSS und eventuelle Scriptsprachen gelesen, liegen bereits die nächsten Steine bereit, den enthusiastischen Webdesigner zu Fall zu bringen. Browserübergreifendes Design, Barrierefreiheit, SEO, Unobtrusive JavaScript – das sind nur ein paar der Stichworte, die einem früher oder später entgegen fliegen.

Damit Sie in diesem Dschungel nicht hilflos dastehen, geben wir Ihnen 10 Links zu Onlinetools an die Hand, die Ihnen das Leben etwas leichter machen:

Mehr