Umgang mit generierten Sourcen

Eben mal kurz Generation Gap Pattern nachgeschlagen :smiley:

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 :wink:

Die Impl-Klassen sind die konkreten Klassen, wÀr irgendwie blöd die nicht einzuchecken :smiley:

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 :wink:

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 :wink:

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 :wink:

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 :wink: 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?