Frameworks: JUnit4, compile-testing
Artikel: https://www.visma.com/blog/java-annotation-processing-tool-tips-writing-testing/

Beispiel Projekt:
https://github.com/tommy-bo/junit-ignore-processor

@RadesBuilder wird deprecation
@RadesAddBuilder wird neue Annotation
Beide Annotationen werden supported

Der Konstruktor nimmt als einziges Argument eine Klasse auf welche der Builder baut.
Diese kann dann mit dem Builder beliebig modifiziert werden.
Gedacht ist das Vorgehen für Klassen mit Null Feldern. Diese werden irgendwann später nach der Erzeugung gesetzt und hierzu wird wieder ein Builder benötigt.

slf4j mit logback nutzen

child of #109
Für Attribute wie Listen die nicht modifiziert werden sollen - hier kann stattdessen .stream() generiert werden.

Der Accessor gibt aktuell keine überschriebene Repräsentation des Domainobjektes zurück.
Daher sollte die toString() Methode auf deas objekt delegiert werden.

Builder Fachlichkeit wird in einem Package untergebracht um von der zukünftigen Accessor Fachlichkeit getrennt zu liegen

Wenn die Rades Annotationen in anderen Annotationen verwendet werden, dann müssen alle Klassen an denen die anderen Annotationen hängen mit in die Liste zu bauender Builder aufgenommen werden.

Da lombok eine sehr gute und weit verbreitete Lösung bietet sollten gleich am Anfang der README die Gründe stehen warum bzw. wann man dieses Projekt nutzen sollte oder warum es entstand:

• gedacht für Einzelfälle wenn nur mal schnell Builder gebaut werden sollen aber nicht die volle Mächtigkeit von lombok benötigt wird
• Teil einer Toolchain für RADES - sollte also genutzt werden, wenn man ein RADES Projekt oder ein Projekt nach RADES Prinzipien bearbeitet
• Dieses Projekt bietet eine simple und deutlich eingeschränktere Lösung in Bezug auf lombok. Es schränkt den Entwickler ein um später die Einhaltung von RADES Konzepten zu erleichtern.

Die Programme lassen sich in den meisten Firmen erst einsetzen, wenn sie über das maven central verteilt werden.

Logprovider darf nur für den Test konfiguriert werden. Der Produktion Kode darf nur gegen das api programmiert werden

TimeUtil erstellen und im Test mocken

Damit im Test immer der gleiche Zeitstempel genutzt werden kann und nicht die Vergleichsdatei anzupassen ist.

Es müssen Attribute ähnlicher Typen funktionieren:

Map<String, Person>
Set<Farben>

SPIKE Prüfen ob es Vorteile verschafft die sonatype repos aufzunehmen:

<distributionManagement>
  <snapshotRepository>
   <id>ossrh</id>
   <url>https://oss.sonatype.org/content/repositories/snapshots</url>
  </snapshotRepository>
  <repository>
   <id>ossrh</id>
   <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
  </repository>
 </distributionManagement>

Bei dem Auslesen des SimpleClassname vergessen wurden.

Ein Team mit einer Mitgliederliste lässt sich nur modellieren, wenn die mitglieder Liste private ist und die Methoden addMitglied, removeMitglied, getMitglieder:Stream() händisch implementiert werden.
Da die Mitgliederliste aber ein fachliches Attribut ist (im Gegensatz zu einer Id) sollte diese protected setzbar sein ohne, dass ein with im Builder gebaut wird.

Der Builder soll auch Setter für package scope Attribute bereitstellen

Nur Releases als Dependencies nutzen:

@RadesBuilder wird nicht mehr unterstützt

Auf der Console oder in einer Textdatei soll ausgegeben werden welche Anpassungen einmalig manuell durchzuführen sind.
(Falls Datei dann ein ausschaltbar)
z.B. Dependencies in pom.xml ergänzen
Je Processor sollte eine solche Datei erstellt werden, damit es keine Probleme gibt.

Suchen und fixen

Notwendig um ins maven central zu kommen

Es gab ein Plugin - prüfen ob es noch nutzbar ist.
https://github.com/cjnygard/rest-maven-plugin

Das Verschieben der Annotationsklassen in ein anderes Package verursacht beim Endnutzer Aufwände.
Die Tests sollen solche Änderungen sichtbar machen.
Schlagen die Compatibillity Tests fail, so muss die nächste Version ein Major Release Upgrade sein.

Nach Implementierung von issue #1 muss alles wieder korrekt mit JUnit 5 laufen.
Die bestehenden Integrationstests sollen erhalten bleiben.

Branch #52_xxx wurde erstellt

SPIKE wurde zurückgestellt weil er zunächst nicht funktioniert hat - weitere Erfahrungen müssen gesammelt werden.

Probieren ob sich @Inject über die java service spi realisieren lassen.
CDI ist in Java SE zwar eingebaut aber man muss selbst einen Container instanzieren, was im Annotation Processor keinen Sinn ergibt, da keine Main Klasse vorhanden ist. Da die Annotationen auch im Container Umfeld genutzt werden sollen (JavaEE, Pico, spring) dürfte die Erzeugung eines neuen Containers auch nur zu Problemen führen. Daher servic spi nutzen.

Ein Validierungsprovider sollte im PROD Kode nicht notwendig sein, da gegen das API programmiert wird.

Der Endnutzer selbst soll durch eine solche Abhängigkeit nicht eingeschränkt werden.

Alle Methoden, welche vom Domainobjekt bereitgestellt werden, müssen auch vom Accessor bereitgestellt und ans Domainobjekt delegiert werden.
Das sichert einen reibungslosen Workflow. Aus dem Builder den Accessor generiert und diesen benutzt als wäre es das Domainobjekt.

Die Synonyme @NoBuilder und @NoAccessor wurden bei der Implementierung vergessen.

child of #108
Singular baut entsprechend Lombok beim Builder statt setter für Collections add Methoden für Entries
Bearbeitung im branch: #94_collections

Zurückgestellt wegen fachlicher Widersprüche

Implementierung für alle Klassen die das Interface Collection implementieren - add und remove Methoden bereitstellen.

In der build Methode des Builders soll auf der fachlichen Klasse eine Bean Validation durchgeführt werden.
Hiermit wird sichergestellt, dass stets nur fachlich gültige Instanzen gebildet werden können.

Es wird Doku benötigt, welche an Beispielen erklärt, wie die Annotationen zu verwenden sind.

Es müssen erzeugt werden:
Anwendung
Sourcen
Doku

Über einen Parameter der Annotation muss sich der Klassenname der generierten Builder Klasse steuern lassen.

Erstellung einer aussagekräftigen Changelog Datei.

Die generierten Klassen hängen von 3th libs ab.
(apache, validation, ..)
Diese müssen als compile scope im pom.xml definiert werden, da sonst beim Endnutzer eine Meldung "fehlende Abhängigkeit" auftritt.
Das ist zwar richtig und der Endnutzer sollte lieber diese Abhängigkeiten selbst im pom.xml aufnehmen. Dies wird aber nicht jeder Endnutzer verstehen und daher sorgen wir hier für eine implizite Lösung.

@RadesVersion soll im Kommentar folgende Ausgabe bewirken

• @Version version datum

Die Version soll aus ${project.version} und das datum soll heute das checkout Datum sein.

Standarddatentypen wie Date, Integer, Double, Long sollen unterstützt und per Unittests abgeprüft werden

Version 1.0.0 auf Bintray bereistellen.

Durch issue #73 und der damit einhergehenden Teilung des pom in parent und pom wurde ein download Problem für den Maven Build erzeugt.

Die Splittung wird daher zurück genommen und das Projekt rades.forge-addon muss sich einen besseren Weg zur Automatisierung suchen.