Also, ich wollte Lombok schon eine Weile benutzen - und ich starte endlich ein Projekt, wo ich es benutzen kann. Es ist wichtig zu beachten, dass es sich um eine große Anwendung der Enterprise-Klasse handelt. Daher müssen die verwendeten Integrationsmuster aussagekräftig sein und möglichst wenige Hacks enthalten.
Also habe ich mir das Lombok-Maven-Plugin angeschaut und den ganzen delombok fudge. Ich verstehe, dass dies meinen gesamten Code duplizieren und die Lombok-Anmerkungen, sofern vorhanden, erweitern wird. Dies gibt mir einen zweiten Satz von generierten .java -Dateien, die von Maven während der Kompilierung verwendet werden müssen.
Wenn Sie jedoch diese neuen Quelldateien erstellen, werden Sie von eclipse abgeholt und versucht, sie in mein Projekt zu ziehen. So feuert es eine Million (OK, leicht übertrieben) Fehler über doppelte Klassen.
Einige Lösungen schlagen vor, dass ich die <sourceDirectory> in meinem POM ändere. Das macht die Sache nicht besser, da mvn eclipse:eclipse jetzt mein src/main/java java -Verzeichnis vollständig aus dem Projekt auslässt - nur die Ausgabe des Delombok-Prozesses zeigend.
Dann kommen die Vorschläge, die ich brauche, um ein Profil zu verwenden, um das Projekt zu kompilieren / zu packen, und ein anderes zu mvn eclipse:eclipse . Dies ist keine akzeptable Lösung, da ich genug Zeit damit verbringen muss, mein bereits komplexes Maven-Setup beizubehalten / zu erklären - ohne ein komplett neues Profil (zusätzlich zu meinen bestehenden Profilen) einführen zu müssen.
Ich hoffe auf etwas Inspiration, um mich davor zu bewahren, Lombok für mein Projekt abzuschreiben. Es ist ein großartiges Werkzeug, um den Standardcode zu reduzieren, aber es scheint einfach nicht für die Prime-Time-Enterprise-Nutzung bereit zu sein - was ich sehr enttäuschend finde: - (
Das Folgende ist mein derzeitiges POM:
%Vor%Was derzeit nur den deluchierten Code in mein Eclipse-Projekt einbindet.
Schlussbemerkung - Ich bin auch ziemlich frustriert, dass ich Lombok manuell auf allen Eclipse-Instances installieren muss, die wir verwenden werden. Hauptsächlich, weil ich der Anruf von allen Entwicklern bekomme, die es nicht funktionieren lassen. Ich verstehe, warum es nicht so einfach ist wie mvn eclipse:eclipse , aber ich wollte immer noch meine Enttäuschung feststellen. Wenn wir jede Bibliothek manuell für die Verwendung auf dem Rechner jedes Entwicklers einrichten müssten, wären wir in den Tagen vor den Maven zurück.
Sie müssen nicht unbedingt lombok-maven-plugin verwenden, um Lombok zu nutzen. Wie ich verstehe, soll die delombofication , die das Plugin macht, Dingen wie Code-Coverage und javadoc erlauben, eine Vollversion des Codes zu haben. Selbst dann würde der Prozess nur etwa zur Javadoc-Bauzeit stattfinden.
Die Frage ist, ob Ihr Projekt ohne das leben kann. Wenn ja, dann fügen Sie einfach Lombok als Maven-Abhängigkeit hinzu.
In Eclipse müssen Sie es tatsächlich installieren. Beachten Sie, dass die Tatsache, dass der Lombok noch immer experimentell ist, vielleicht für die Gründe ist, warum er nicht standardmäßig in Eclipse enthalten ist.
Wir setzen Lombok seit 1,5 Jahren erfolgreich in unserem Projekt ein. Wir verwenden keine Delombokifikation, sondern haben Lombok als eine gelieferte Abhängigkeit wie folgt.
%Vor%Mehr braucht es nicht. Wir können die Lombok-Annotationen verwenden und sie werden sowohl von Eclipse- als auch von Maven-Builds erkannt. Dies ist sogar kompatibel mit EclEmma in Eclipse, das die Annotationen als (un) abgedeckt markiert, wenn der jeweilige generierte Code (nicht) ist.
Sie müssen es manuell auf jeder Eclipse-Instanz installieren, da der größte Teil des JDT nicht für die Änderung von Eclipse-Plugins geöffnet ist. Das ist eine technische Einschränkung, die die Lombok-Entwickler nicht bewältigen können. Wie auch immer, der Installer ist ziemlich einfach und hat mich bis jetzt nie im Stich gelassen.