Eben mal kurz Generation Gap Pattern nachgeschlagen 
Es werden auch bei uns nur die Impl-Klassen eingecheckt, generierter Code muss halt aus dem Modell nochmal generiert werden.
Wir benutzen allerdings ein anderes Modellierungstool als EMF.
Was heißt hier auch :D? Bei mir werden keine generierten Impl Klassen eingecheckt…
[QUOTE=Shadoka;69519]
Wir benutzen allerdings ein anderes Modellierungstool als EMF.[/QUOTE]
Kannst mal glänzen in deiner Firma und einen guten Vorschlag für eine Verbesserung machen 
Die Impl-Klassen sind die konkreten Klassen, wär irgendwie blöd die nicht einzuchecken 
Unser eingesetztes Tool ist ziemlich mächtig, wird nicht nur für Klassenmodelle eingesetzt, sondern auch um Persistenzschicht zu generieren, BPMN und anderes.
[QUOTE=Shadoka]Die Impl-Klassen sind die konkreten Klassen, wär irgendwie blöd die nicht einzuchecken :D[/QUOTE]Generiertes wird grundsätzlich nicht eingecheckt, auch wenn es Impl-Klassen sind.
bye
TT
Impl-Klassen werden einmalig generiert und bei erneutem Generieren nicht überschrieben. Ist schon in Ordnung so.
Verstehe ich nicht. Es wird generiert. Das wird eingecheckt. Dann wird das bei erneuter Generierung aber nicht überschrieben? Klingt komisch.
[QUOTE=Shadoka]
Unser eingesetztes Tool ist ziemlich mächtig, wird nicht nur für Klassenmodelle eingesetzt, sondern auch um Persistenzschicht zu generieren, BPMN und anderes.[/QUOTE]
Jo und jetzt? Es gibt soviele Projekte die auf EMF aufbauen und mächtige Sachen machen:
- CRUD Webservices
- Persistzenschicht
- DSL + UI
- Workflow Systeme + UI
- Model Verteilung + Persistieren + Update auf verschiedene Knoten + verschiedene Persistierung Schichten usw.
…
…
*** Edit ***
Ja wahrscheinlich weil das Framework kein Generation Gap kann, um Customize Code reinzubringen muss dann sowas gemacht werden…
Ich würde vorziehen die Diskussion an dieser Stelle abzubrechen, ein Wechsel des Tools steht außer Frage, da es dafür bereits eine definierte Designsprache gibt, Prozesse und was damit noch alles zusammenhängt. Das Unternehmen gibt es auch schon ziemlich lange und es gibt einfach viele Konstrukte die „historisch gewachsen“ sind 
Denke auch dass man an dieser Stelle diese Diskussion in einen eigenen Thread verlagert (“Umgang mit gnerierten Sourcen” oder so), sind schon etwas von der Ausgangsfrage hier abgekommen.
Wo geht die Diskussion denn weiter? Ich checke generierte Klassen auch immer ein, z.B. ORM Entities. Das Schema dazu ist schließlich auch versioniert. Der Vorteil ist, dass man ein lauffähiges Projekt hat nach einem checkout. Sowohl für Entwickler gut, als auch für CI/CD.
maki trennst du das Thema auf?
Für welche Entwickler, die nicht clean install aufrufen können?
Warum ist es gut für den CI?
Vor allem die schönen Änderungen wenn der Code mal anders formatiert wird und es nur line endings sind die anders sind…
Generierte Klassen nicht einchecken so kommt keiner auf die Idee solche Dateien von Hand zu ändern, dass ist gut für den Entwickler
Checkst du deine *.class Dateien auch ein :)?
Also ein mvn clean install generiert bei mir keine Hibernate Entities. Wenn man Tests hat, die nunmal die generierten Klassen brauchen bzw. ein lauffähiges konsistentes Programm, dann muss der CI Server die Klassen nicht generieren, was sich auch nicht in jedem Fall so einfach möglich wäre.
Tja selbst Schuld
He ja und? Bekommt man auch hin wenn die Klassen zur Buildzeit generiert wird, dafür ist Maven ja da…
Natürlich ist alles machbar, das bestreitet niemand. Die Frage ist eher was dagegen spricht generierten Code einzuchecken?
Es kommen immer wieder schlaue Entwickler auf die Ideen generierten Code zu ändern und bei der nächsten Generierung ist er weg…
Wie gesagt checkst *.class Dateien an?
Da gibt es viele Gründe. Wenn Du die bei jedem Build einfach generieren kannst, kannst Du sicher sein, dass die Entities zum aktuellen Schema passen. Zudem kommt niemand auf die Idee, generierte Klassen zu erweitern. Und niemand kann einfach alten Code auschecken und wundert sich nach dem Build (ohne Generierung), warum der Server nicht läuft. Zuletzt wird bei jedem Build somit automatisch geprüft, ob die Generierung noch tut.
*** Edit ***
Die Frage trifft es ziemlich genau.
Das ist doch kein Grund, schließlich liegt generierter Code auch separat, z.B. in eigenen Packages.
Natürlich checke ich .class Dateien nicht ein, das ist auch nicht das selbe. Wie gesagt, generierte Klassen machen erst das Projekt konsistent und lauffähig, .class Dateien kommen erst später.
Und wenn ich z.B. in PHP daran denke in jeder Umgebung die Entities erst generieren lassen zu müssen, bevor das Projekt oder die Tests laufen können…das würde extra implementiert und in allen entsprechenden Umgebungen integriert werden müssen, ganz zu schweigen von der Wartung dieses Skriptes.
Wer generierten Code anfasst macht das meist nur ein einziges Mal Dafür gibt es Code Reviews.
Gut der Code Review bei generierten Klassen fliegt ja dann wohl weg :), wieder ein Grund mehr.
Wir haben dir genügend Gründe genannt. Du hast nur ein Grund genannt du hast alle Sourcen beim Auschecken, aber noch lange müssen deine Projekte darum nicht laufen z.B. werden dependencies auch durch deine Buildumgebung angezogen…
Wie jetzt, warum fliegt der Code Review bei generierten Klassen weg? Der gesamte Commit wird natürlich gereviewt. Gemeint war, wenn Entwickler A generierte Klassen committed, dann kann das verdächtig sein, weil Entwickler A normal keine generierten Klassen committen sollte. Zumindest kenne ich das so, dass für Generierung von Klassen meist nur wenige Entwickler zuständig sind, wenn nicht sogar nur einer. Alle anderen wissen oft nichtmal wie man die Klassen generiert oder haben nicht die passende Infrastruktur dafür, z.B. aktuelle Datenbank, Skript, Rechte, etc. Es gibt genügend Gründe bei sowas, ist aber eher abhängig von organisatorischen Gründen.
Über Dependencies habe ich mir auch gerade Gedanken gemacht, die checke ich nämlich auch nicht ein, zumindest nicht seit Maven in Java und Composer in PHP. Davor allerdings schon, was mich aber immer störte.
Ich finde aber genau wie .class Dateien sind auch Dependencies nicht vergleichbar mit den generierten Klassen. Schließlich ist man von den generierten Klassen der Hersteller, wenn auch nur indirekt. Man ist also für die Korrektheit der generierten Klassen verantwortlich, daher sollte man möglichst viel Kontrolle über den Stand dieser Komponenten haben, sei es Vollständigkeit oder ähnliches. Und das kann man am besten, wenn das Projekt immer in der Gesamtheit vorliegt. Ansonsten würde ich mir evtl. lokal eine vollständige Projektumgebung herstellen durch die Generierung, aber in anderen Umgebungen wird evtl. eine Klasse nicht generiert, weil die Datenbank nicht aktuell ist.
Ich möchte also den Fehler in dieser Umgebung mitbekomen, damit ich die DB aktualisieren kann, statt in der Umgebung ein scheinbar vollständiges Projekt zu haben, weil es auf einem alten Stand läuft.
Du widersprichst dir gerade selber. Einmal gut einmal nicht gut, dann lieber einheitlich…
Was gibt es den aktuelleres, wie wenn der Code auf dem CI neu generiert wird aus dem aktuellen Model neuer gehts nicht? Bei euch ist nur ein Entwickler dafür zuständig armer Betrieb wenn der das Unternehmen verlässt…
Ich habe noch keinen Vorteil jetzt entdecken können?