Gehört generierter Code in die Versionsverwaltung

[Gast2]

Hallo zusammen,

ich habe schon einige Projekte gesehen bei denen generierter Code von wsdl's (JaxB) oder genmodel (EMF) in die Versionsverwaltung eingecheckt wurden, aber auch einige Projekte gesehen bei denen das ein Buildtool (z.B. Maven) während dem Einrichten des Projektes gemacht hat und der Code nicht eingecheckt wurde.
Wie handhabt ihr das in eurem Projekt und welche Vor- bzw. Nachteile haben sich daraus ergeben?

 

[Gast2]

Wir checken nur echte sourcen ein. Code der generiert wird ist imho auch ein build aus einer anderen Source, welcher nicht eingecheckt wird.

Die HelpSets z.B. werden bei uns aus docbook Dokumenten generiert welche eingecheckt sind. Die JavaHelp Sets selber sind auch in den properties eingetragen, jedoch vor dem ersten Build nicht vorhanden (und werden z.B. von Eclipse als Fehler gemeldet weil sie fehlen).

Es gibt zu dem Workspace eine kurze Anleitung welche Tools installiert werden müssen und welche Prozesse einmalig ausgeführt werden müssen um einen konsistenten Workspace zu bekommen.

Das handhaben wir eigentlich überall so.

 

[mvitz]

Generell checke ich Dinge, die automatisch generiert werden können nicht ein, denn diese sind ja einfach beim nächsten Build wieder zu generieren.

Ausnahme (jedoch bei mir noch nicht vorgekommen): Sollte das generieren lange dauern, könnte man dazu übergehen diese Sachen doch einzuchecken, damit der Build nicht ewig dauert.

 

[fastjack]

Die generierten "Sachen" können, sofern es Java-Sourcen sind, kompiliert werden und als Jar in ein Repository gelegt werden. Dann muß auch nicht jeder Entwickler bei sich generieren usw.

 

[Gast2]

Die generierten "Sachen" können, sofern es Java-Sourcen sind, kompiliert werden und als Jar in ein Repository gelegt werden. Dann muß auch nicht jeder Entwickler bei sich generieren usw.

Genau das gilt es doch zu vermeiden! Builds zu versionieren. Das ist absolut überflüssig, da doppelt gemoppelt!

 

[fastjack]

Dann denk mal einen Schritt weiter. Ich meine kein SVN, sondern z.B. ein Maven Repository.

 

[fastjack]

@kappesf Das Problem ist, daß wenn Ihr bei Euch auscheckt, womöglich gar nicht merkt, ob neu generiert werden muß oder nicht. Whl. wird dann bei jedem Build immer generiert... suboptimal finde ich. Was wie mvitz schon andeutete bei größeren Generierungen lange dauern kann..

 

[Gast2]

Also meine Erfahrung ist, dass generierter Code meistens eingecheckt wird, weil an diesem Code etwas verändert werden muss muss und das Framework KEIN GenerationGap unterstützt

.

Zu EMF: EMF unterstützt leider auch nicht out of the box GenerationGap. Aber hab raus gefunden, dass es nachgebaut werden kann (mwe2 File) und somit muss der generierte Code nicht eingecheckt werden, sondern nur der customize Code...

 

[Gast2]

Also meine Erfahrung ist, dass generierter Code meistens eingecheckt wird, weil an diesem Code etwas verändert werden muss muss und das Framework KEIN GenerationGap unterstützt

.

In so einem Fall sollte der Code natürlich eingecheckt werden. Er ist aber auch dann streng genommen nicht mehr generiert auch wenn er auf generiertem Code basiert.

Code / Resourcen die 100% erstellt werden können sollten nicht eingecheckt werden.

 

[Gast2]

In so einem Fall sollte der Code natürlich eingecheckt werden. Er ist aber auch dann streng genommen nicht mehr generiert auch wenn er auf generiertem Code basiert.

Code / Resourcen die 100% erstellt werden können sollten nicht eingecheckt werden.

Wie gesagt mit EMF hab ich nun eine Möglichkeit gefunden, dass Custom Code berücksichtigt wird.

 

[fastjack]

Ich fasse mal meine Erfahrungen zusammen:

Generierter Code ins SVN

Nachteil: Je häufiger verschiedene Leute Templates anpassen und generieren, desto häufiger hat man Merge-Probleme. Falls man auch noch Zeitstempel im File-Header hat oder so, knallts immer

Vorteil: Beim Auschecken ist alles fix und fertig da

Generierter Code nicht ins SVN

Nachteil: Jeder Entwickler muß oft Code generieren, zumindest bei jeder Template-Änderung. Bei großen Projekten/Team kann das problematisch sein, da man einfach verschwitzt Code zu generieren, obwohl man es eigentlich müßte.

Vorteil: Keine SVN-Konflikte

Bei jedem Build automatisch generieren

Nachteil: Kann bei großen Projekten und bei viel generiertem Code dauern, was den ganzen Build verzögert.

Vorteil: Keine SVN-Konflikte. Änderungen werden gleich generiert, also kein "alter" generierter Code mehr.

Generierung, anschließendes Kompilieren, Jar-Datei mit kompiliertem Code ins Maven-Repo

Nachteil: sehe ich keinen, wenn Maven-Repo nicht verfügbar wird aufs lokale zurückgefallen und man muß lokal generieren

Vorteil: alles fix und fertig, immer und zu jeder Zeit, für jeden Entwickler.

 

[KSG9|sebastian]

Folgendes kann ich aus bisherigen Projekten/Kunden berichten:

1. 100% generierter Code wird meist nicht eingecheckt, da in der IDE bzw durch CI-System generiert

2. Code welcher sehr lange benötigt um generiert zu werden landet meist im SVN

3. Änderungen im generierten Code ohne 100%ige Generation-Gap-Unterstützung ist eine absolute Vollkatastrophe.

In dem Fall sind wir immer so vorgegangen:

- Generierter Code landet in einem eigenen Sourcefolder (src-gen)
- bei Klassen welche nachträglich geändert werden wurde eine zweite Klasse generiert (nur einmal generiert) welche die generierte Klasse erweitert, dort wurden entsprechende Änderungen vorgenommen

-src/gen

class GenClass{
..
}

- src/xyz

class ModGenClass extends GenClass{
..
}

ModGenClass wird nur einmal generiert, bzw. nur dann generiert wenn sie nicht existiert.

Optimal ist natürlich ein MDE/MDA-Tool welches Generation-Gap unterstützt.

 

[Gast2]

3. Änderungen im generierten Code ohne 100%ige Generation-Gap-Unterstützung ist eine absolute Vollkatastrophe.

Seh ich auch so.

In dem Fall sind wir immer so vorgegangen:

- Generierter Code landet in einem eigenen Sourcefolder (src-gen)
- bei Klassen welche nachträglich geändert werden wurde eine zweite Klasse generiert (nur einmal generiert) welche die generierte Klasse erweitert, dort wurden entsprechende Änderungen vorgenommen

-src/gen

class GenClass{
..
}

- src/xyz

class ModGenClass extends GenClass{
..
}

Wenn du dann aber mit Factories arbeitest, musst du diese immer von Hand anpassen sobald du eine ModGenClass hast, auch ziemlich aufwendig.

btw: eigener Sourcefolder (src-gen) würde ich sowieso immer empfehlen.

Generierter Code nicht ins SVN
Nachteil: Jeder Entwickler muß oft Code generieren, zumindest bei jeder Template-Änderung. Bei großen Projekten/Team kann das problematisch sein, da man einfach verschwitzt Code zu generieren, obwohl man es eigentlich müßte.

Es gibt ja auch Templatesprachen die on the fly, sobald du in der IDE speicherst dir Java Klassen erzeugt (xTend), ziemlich coole Sache.

 

[cljk]

Seh ich auch so.
Es gibt ja auch Templatesprachen die on the fly, sobald du in der IDE speicherst dir Java Klassen erzeugt (xTend), ziemlich coole Sache.

xTend kann on the fly generieren? Seit wann das denn?
Meine letzten (grauenvollen) Erfahrungen liegen schon ein paar Jährchen zurück... muss ich mir wohl mal wieder ansehen.

Schonmal eine Vorabfrage, die du ggf. beantworten kann: gibts da auch ein Maven-Plugin für?

 

[Gast2]

xTend kann on the fly generieren? Seit wann das denn?
Meine letzten (grauenvollen) Erfahrungen liegen schon ein paar Jährchen zurück... muss ich mir wohl mal wieder ansehen.

Schonmal eine Vorabfrage, die du ggf. beantworten kann: gibts da auch ein Maven-Plugin für?

Ja solltest du mal anschauen: Sobald du das Template speicherst wird JavaCode erzeugt (vorrausgesetzt du hast die Eclipse Plugins).

Maven-Plugin gibts auch
[XML]
<build>
<plugins>
<plugin>
<groupId>org.eclipse.xtend2</groupId>
<artifactId>xtend-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
</dependencies>
</plugin>
</plugins>
</build>
[/XML]