JAXB generell auf XMLs übertragbar

[nrg]

Hallo Zusammen,

ich arbeite derzeit an einer Library für eine Schnittstelle. Diese kommuniziert über XML-Requests und Responses. Bisher habe ich alle XMLs in Klassen abgebildet. Das Parsen der XMLs in Klassen und umgekehrt mache ich mit dom4j und xpath. Das funktioniert auch sehr gut aber jetzt habe ich mir überlegt, ob vielleicht JAXB hier auch denkbar ist. Das manuelle Abbilden der XMLs ist nämlich sehr aufwendig.

Also meine Frage: kann ich beliebige XMLs unmarshallen?

Vllt ein kleines Beispiel (nur mal kurz zusammengetippt):
[XML]
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Test>
<List>
<Element prop1="1" prop2="2" />
<Element prop1="5" prop2="6" />
</List>
<OtherList>
<OtherElement stringprop1="asdf" prop4="2">Some Text</OtherElement>
<OtherElement stringprop1="hello" prop4="6">Some Text</OtherElement>
</OtherList>
</Test>[/XML]

wird zu:

public class Test {
	private List<Element> list;
	private List<OtherElement> otherList;
	
	// ....
}

public class Element {
	private int prop1;
	private int prop2;

	// ....
}

public class OtherElement {
	private String stringprop1;
	private String text;
	private int prop4;

	// ....
}

die XMLs folgen keiner Schema Definition. Ich kann mir schwer vorstellen, dass ich eher willkürlich definierte XMLs mal so eben in Java abbilden kann hab aber mit JAXB bisher auch noch nichts gemacht (wichtig ist halt, dass auch was sinnvolles dabei rauskommt - bzgl. datentypen, referenzen, vererbung).

Grüße
nrg

 

[Wildcard]

Um XML automatisiert an Java Klassen zu binden brauchst du nicht unbedingt ein physikalisch vorhandenes Schema, aber die XML Dateien müssen trotzdem einem Schema folgen. Woher soll ein Codegenerator sonst wissen das es ein Property X und eine Klasse Y geben wird.
JAXB ist allerdings IMO nicht das ideale Werkzeug, EMF ist deutlich besser.

 

[nrg]

Um XML automatisiert an Java Klassen zu binden brauchst du nicht unbedingt ein physikalisch vorhandenes Schema, aber die XML Dateien müssen trotzdem einem Schema folgen. Woher soll ein Codegenerator sonst wissen das es ein Property X und eine Klasse Y geben wird.

dann wird das wohl nichts

JAXB ist allerdings IMO nicht das ideale Werkzeug

meinst du generell oder nur für mein vorhaben?

EMF ist deutlich besser.

danke, schau ich mir mal an

 

[Wildcard]

Mir ist nicht klar wie du dir das vorstellst.
Wo sollen denn die Java Klassen überhaupt herkommen auf die du ein beliebiges XML binden willst?
Oder hast du erwartet das beim einlesen der XML passende Java Klassen erzeugt und kompiliert werden ???:L

meinst du generell oder nur für mein vorhaben?

Generell sehe ich keinen Grund JAXB benutzen zu wollen.

 

[nrg]

Mir ist nicht klar wie du dir das vorstellst.
Wo sollen denn die Java Klassen überhaupt herkommen auf die du ein beliebiges XML binden willst?
Oder hast du erwartet das beim einlesen der XML passende Java Klassen erzeugt und kompiliert werden ???:L

nein, natürlich nicht. die frage ist für mich, wie umfangreich die annotationen sind. die grundstruktur hätte man mit trang und xjc machen können und den feinschliff dann im generierten javacode. aber wenn das ein "fass ohne boden" ist, schlage ich mir das vorhaben direkt wieder aus dem kopf.

 

[Wildcard]

Der sauberste Weg ist ein Schema für die XML Dateien zu schreiben und daraus die Klassen erzeugen zu lassen. Alleine die Tatsache das du von 'feinschliff im generierten code' sprichst, heißt doch schon das es nicht irgendwelche Beliebigen Daten sind, sondern sie einem Schema folgen. Das Schema wurde bisher nur nicht formalisiert.
Wenn du diese Formalisierung nun durchführst (das ist nicht schwierig), dann ist das einerseits ein wichtiges Stück Dokumentation und andererseits brauchst du ab diesem Zeitpunkt keinerlei eigenen Code mehr zu schreiben um diese XML Daten zu lesen zu zu schreiben.

 

[nrg]

dann haben wir aneinander vorbeigesprochen. ich dachte du meinst ein JAXB spezifisches schema (wie gesagt, ist das noch etwas neuland für mich). also bestimmte konventionen, die einfach eingehalten werden müssen, um mit JAXB zu arbeiten. einem allgemeinen schema folgen die XMLs natürlich, sonst könnte ich sie ja selbst nichtmal parsen

 

[Wildcard]

Also, dann hast du es einfach. Aus der XSD brauchst du nur Java Klassen zu generieren und der Rest funktioniert automatisch.
EMF erzeugt viel bessere Klassen als JAXB, die du auch händisch bearbeiten kannst (EMF kann händischen Code mit generiertem Code immer wieder aufs neue mergen) und hat auch sonst mehr Features, aber dafür musst du EMF in den Classpath deines Projekts aufnehmen. JAXB ist mittlerweile in die JRE integriert, du brauchst also keine Bibliothek mehr (und das ist IMO auch der einzige Grund warum man freiwillig zu JAXB greift).
Die Grundsätzliche Aufgabe, die XML in Java Objekte zu überführen, werden beide Tools problemlos meistern und beide Tools sind deinem bisherigen jdom + xpath Ansatz vorzuziehen.

 

[musiKk]

Um mal wieder den Gegenpol zu stellen, damit das nicht zu einseitig wird.

Gerade wenn man in Richtung Web Services denkt, ist JAXB unumgänglich. JAX-WS verwendet JAXB, um Objekte zu (un)marshallen.

Mit JAXB nehme ich meine Klassen und muss im Idealfall gar nichts machen. Ich werfe das dem Marshaller hin und bin fertig. Ich sehe gar nicht ein, auf Tools wie EMF Editoren und externe Abhängigkeiten zurückgreifen zu müssen, um sowas machen zu können.

Das einzige Argument das ich kenne, was für EMF spricht, ist die Fähigkeit eigenen Code ins Modell mergen zu können. Da gibt es für einige Dinge wie [c]Comparable[/c] und [c]toString()[/c] auch Plugins für JAXB, aber super ideal ist das sicher nicht. Komischerweise habe ich das nie benötigt. Kann aber auch daran liegen, dass ich den "Code first"-Ansatz verfolge und die Klassen in leicht wiederverwendbare Module stecke. Generiert wird dabei nie etwas.

Das soll wie immer nicht als Flame gelten. Ich bin nur der Meinung, dass JAXB den meisten Anforderungen genügt und nicht einfacher bedienbar sein könnte.

 

[nrg]

ich bin halt immernoch nicht ganz davon überzeugt, ob der Lösungsansatz (sei es jetzt JAXB oder EMF) Hand und Fuß hat. Die Request XMLs sehen sehr identisch aus. Ich weiß noch nicht ganz, wie ich daraus automatisch Klassen erzeugen soll, die dann auch sinnvoll aufgebaut sind. Aber dafür kenne ich die Technologien noch zu wenig. Ich lese mich mal rein und probiere ein wenig rum (gerade bin ich auch nicht von JAXB abgeneigt, weil mir das Argument "No Dependencies" sehr gut gefällt)

 

[nrg]

also wenn ich mit trang die XMLs in XSDs umwandle und daraus dann mit xjc Klassen erzeuge, kann sich das Resultat nicht gerade sehen lassen (hätte mich auch ehrlich gesagt ein wenig gewundert). ich werde jetzt mal dahin gehen meine eigenen Klassen zu annotieren. dann würde ich mir schonmal das parsen mit dom4j sparen und hätte zudem zwei dependencies weniger. EMF sieht auf den ersten Blick sehr mächtig aus aber halte ich für eine "Low-Weight-Library" zu hoch gegriffen.

 

[mvitz]

Wenn du mal eine Beispiel XML posten kannst, könnte man dir für das Schema evtl. helfen.

 

[Wildcard]

Mit JAXB nehme ich meine Klassen und muss im Idealfall gar nichts machen. Ich werfe das dem Marshaller hin und bin fertig. Ich sehe gar nicht ein, auf Tools wie EMF Editoren und externe Abhängigkeiten zurückgreifen zu müssen, um sowas machen zu können.

Ich verstehe durchaus das man anderer Meinung sein kann und fasse das auch garantiert nicht als 'Flame' auf, es ist immer gut mehr als eine Sicht zu kennen.
Mein Hauptproblem mit JAXB ist die ganze Bean Geschichte. Man bekommt einen ganzen Haufen Klassen die völlig nutzlos sind, ausser das sie Compile Time Sicherheit bieten.
Für mich ist das Modell das Herz einer jeden Anwendung und dafür eignet sich JAXB nicht.
Wenn man tatsächlich mit den Daten aus der XML arbeiten möchte, dann muss man ein JAXB Modell in ein Domain Modell überführen um dort Business Logik usw. unterzubringen. Für mich ist das dann nicht nicht mehr viel besser als die XML als DOM zu parsen und in ein Modell zu überführen.
Ausserdem stört mich das JAXB das Modell nicht konsistent halten kann. Es gibt keine Opposites und kein automatisch forciertes Containment.
Als Beispiel, ich habe eine Klasse Node mit

public Node getParent();

public List<Node> getChildren();

Mit EMF funktioniert nun folgendes:

Node parent = factory.createNode();
Node child = factory.createNode();
child.setParent(parent);
assertSame(child,parent.getChildren().get(0));

parent.getChildren().remove(child);
assertNull(child.getParent());

Bei den JAXB generierten Klassen muss ich mich um solche Kleinigkeiten selbst kümmern und das ist eine Fehlerquelle.
Weiterhin stört mich, das JAXB nur für XML Use-Cases gedacht ist. Wichtig ist das Modell, nicht die Persistenz des Modells. Bei EMF ist es egal ob ein Modell nun per XML, XMI, binär, objektrelational oder Textuell gespeichert wird und das gibt mir Flexibilität für meine Anwendung.

EMF nicht zu verwenden weil man keine Bibliothek einbinden möchte halte ich für ein Nachvollziehbares Argument. EMF nicht zu verwenden weil man durch externe Requirements zu JAXB gezwungen ist kann ich ebenfalls erklären.
Aber funktional hat mir noch bisher noch niemand einen Bereich zeigen können in dem JAXB besser, oder zumindest ebenbürtig wäre (gibt es vielleicht, würde mich interessieren).

 

[mvitz]

Ich glaube, dass genau hier der Unterschied liegt, nämlich im Ansatz den du mit EMF verfolgst und der Problemstellung, die viele hier im Forum mit XML Binding haben.

Ich kenne EMF bisher nur durch die Hinweise deinerseits und finde, dass man aus deinen vielen Beispielen und Erläuterungen schon erkennen kann, dass EMF wesentlich mächtiger ist. Allerdings ist es imho aus diesem Grunde (zurecht) auch etwas komplexer und braucht ein wenig mehr Zeit zum einarbeiten, was auf den ersten Blick viele abschreckt.

Der zweite Grund, der meiner Meinung nach eben für JAXB spricht ist der, dass wenn man ein reines XML Binding braucht und das evtl. sogar nur für Teile/Ausschnitte seiner Domänenobjekte, dann reicht meiner Meinung nach JAXB in ~90% der Fälle aus. Für die restlichen 10% der Fälle sollte man dann eben auf jeden Fall EMF nehmen oder bei geringem Aufwand mit JAXB Binding Customisations arbeiten, wenn das ausreicht.

Kurz zusammengefasst: Wenn man nur wenige Klassen hat und wirklich nur ein XML Binding benötigt, halte ich JAXB für besser, denn weniger Komplex und im JDK enthalten, ansonsten wird sich eine Einarbeitung in EMF bestimmt lohnen, denn EMF ist JAXB in seiner Funktionalität definitiv überlegen.

Evtl. sollte man hier ein paar Beiträge in ein generelleres "JAXB vs EMF" Thema absplitten?

 

[Wildcard]

Ich kenne EMF bisher nur durch die Hinweise deinerseits und finde, dass man aus deinen vielen Beispielen und Erläuterungen schon erkennen kann, dass EMF wesentlich mächtiger ist. Allerdings ist es imho aus diesem Grunde (zurecht) auch etwas komplexer und braucht ein wenig mehr Zeit zum einarbeiten, was auf den ersten Blick viele abschreckt.

Ich sehe das überhaupt nicht so. Für JAXB gibt es keine Werkzeuge die mir die Arbeit erleichtern, nur Annotations, Ant Tasks usw. Bei EMF kannst du mit Eclipse per Wizard ein XML Schema importieren, du kannst ein UML Diagramm verwenden, du kannst dein Modell per Ecore Diagramm erstellen, du kannst wie bei JAXB Annotations verwenden, du kannst einen grafischen Baumeditor verwenden, oder eine textuelle Syntax wenn dir das besser liegt. Du kannst beliebig zwischen diesen Methoden hin und herwechseln. Warum soll das komplizierter als bei JAXB sein, wo du null Toolunterstützung bekommst?
Ein Anfänger mit einem XML Schema braucht ca. 7 Klicks um zu einem fertigen Modell zu kommen und bekommt auch gleich Example Code generiert der Demonstriert wie man nun eine solche XML lädt, verändert und speichert.
Von JAXB kann man nicht unbedingt das gleiche Behaupten.

Der zweite Grund, der meiner Meinung nach eben für JAXB spricht ist der, dass wenn man ein reines XML Binding braucht und das evtl. sogar nur für Teile/Ausschnitte seiner Domänenobjekte, dann reicht meiner Meinung nach JAXB in ~90% der Fälle aus. Für die restlichen 10% der Fälle sollte man dann eben auf jeden Fall EMF nehmen oder bei geringem Aufwand mit JAXB Binding Customisations arbeiten, wenn das ausreicht.

Ich bewerbe hier EMF, weil ich von dem Tool überzeugt bin. Weil man damit unglaublich viel produktiver wird und die erzeugten Modelle besser sind als alles was ich per Hand schreiben kann.
Wir verwenden im Team für alles was nur entfernt nach Modell riecht EMF, weil es viel stabiler und kostengünstiger ist als es per Hand zu entwickeln.
Der Fehler ist IMO sich nur auf XML Binding beschränken zu wollen, dann das Modell ist das eigentlich wichtige, die Persistenz ist nur ein Teil des Problems.
Ich verwende auch EMF wenn weit und breit nichts von XML zu sehen ist, weil es IMO keinen Sinn macht die gleiche Art von Code immer und immer wieder von Hand schreiben zu müssen.
Das der Ansatz nicht auf jeden passt, mag sein, aber die meisten kennen EMF nicht und daher werbe ich dafür, weil ich weiß, das es sich lohnt.
Einige Member hier melden sich öfter mal zu Wort das ein bestimmtes Problem mit Scala viel eleganter zu lösen ist. Ich finde das grundsätzlich gut, denn auch wenn es oft keine direkte Antwort auf die Frage ist, der meist betretene Weg ist nicht immer der beste und gute Open Source Software wird nur durch Werbung einer begeisterten Community zum Erfolg.

 

[mvitz]

Habe ja auch gar nichts gegen deine Werbung, ganz im Gegenteil, muss mir EMF auch unbedingt mal anschauen.

Aber du musst eben auch sehen, dass nicht jeder heutzutage schon derart mit Modellen arbeitet/in Modellen denkt, wie du bzw. ihr das macht. Und wenn man eben wirklich nur XML Binding braucht (die Fälle gibts es ja auch), dann ist eben ganz viel von EMF unnötig. Und gerade das, was du da aufschreibst, ich kann X, Y und Z auch machen, macht EMF eben etwas komplexer als JAXB imho. Für JAXB weiß ich, es gibt X Annotationen und ich weiß genau was die machen. Zudem ist XSD zu Java mit JAXB auch nicht das Problem (ok, wenn man kein Build Script nutzt ist es komplizierter).
Dein Argument bezüglich Eclipse und EMF lass ich halb gelten, denn nicht jeder nutzt Eclipse als IDE und in andere IDEs ist es dann vermutlich egal ob man ein JAXB oder ein EMF Plugin installiert.

Alles in allem haben wir uns ja auch nicht total widersprochen, ich glaube jedoch auch, dass du natürlich EMF aus einem anderen Blickwinkel siehst, als jemand der es eben noch nicht kennt. Aber das ist normal, ich gerate z.B. immer wieder mit einem Freund zusammen, der mir einfach nicht glauben will, dass ich ne Webanwendung mit Java mindestens genau so schnell hinkriege wie mit PHP, da für ihn alleine das einrichten von Tomcat, dann web.xml, JDBC einrichten etc. ewig dauert. Wenn man das natürlich alles kennt, dann geht das eben schnell und unkompliziert.

 

[nrg]

ich wollte das jetzt eigentlich eher diskret halten aber ich denke von euch kennt eh keiner diese Spezifikation . Ich habe euch mal alles zusammengepackt.

In der zip sind 3 Ordner:
- MySolution: enthält meine derzeitige Lösung (dependencies: dom4j, jaxen, apache httpclient). Unter Test ist auch ein JUnit Test, der euch allerdings nicht viel bringt, weil euch ja die Serverkomponente fehlt . Dieser gibt allerdings Aufschluss darüber, wie die Useage der Library sein soll.
- SampleXMLs: enthält Responses und Requests als Beispiel
- generatedClassesJAXB: enthält die von JAXB erzeugten Klassen (XSDs sind mit trang automatisch erzeugt)

Ich werde die Dateien ca. einen Tag oben lassen. Wäre super, wenn jemand vielleicht kurz die Zeit hat einen Blick darauf zu werfen. Ich möchte die Spezifikation eines Herstellers jetzt aber auch nicht unbedingt öffentlich breitklopfen, deshalb hätte ich nichts dagegen, wenn tiefere Konversationen über PN laufen.

Besten Dank und Grüße

 

[nrg]

kurzes Update: mvitz hat mir via PN etwas geholfen. Nochmal danke dafür. Leider leidet die Usability deutlich, wenn man mit JAXB die Klassen automatisch erzeugt. Ich habe dann viele Unterobjekte, die ich manuell instanziieren und mit Settern referenzieren muss. Das ist nicht wirklich das, was ich mir wünsche und hat sich auch bei meinen Versuchen mit JAXB ähnlich herausgestellt. EMF behalte ich mal im Hinterkopf aber das ist für sowas eher "overkill".
Die XMLs sind wirklich so einfach strukturiert, dass immer ein XPath genügt, um alle Informationen des Response auszulesen. Ich denke damit bin ich ganz gut bedient.

 

[Gelöschtes Mitglied 5909]

@Wildcard:

Bei viele UseCases wird JAXB für Sachen verwendet, die an Schnittstellen anliegen. Und Jaxb ist eben nicht nur auf XML beschränkt.
Es gibt z.b. json provider für JAX-RS. Aber das ist eigentlich auch unwichtig.
Was ich eigentlich sagen wollte, ist dass ich niemals das Modell der Schnittstellen als mein Businessmodell / Persistenzmodell verwenden würde.
Das führt nur zu Problemen.

Du hast auch viele UseCases gezeigt wo es höchstwarscheinlich sinn macht, EMF zu verwenden. Aber gerade für Anfänger (und das ist der TO nach eigenen Angaben) ist Jaxb warscheinlich eher geeignet. Ich muss dazu sagen dass ich EMF auch noch nicht verwendet habe.
Was ich mich (aus unwissenheit) frage:

- wie sieht denn die EMF unterstützung außerhalb von eclipse aus?
- gibt support für maven/ant?
- wieviele dependencies hole ich mir denn durch emf rein?
- generiert man die klassen wie bei jaxb auch immer und immer wieder (würde bedeuten, dass das graphische(?) Modell "master" ist, ähnlich dem xml schema bei jaxb)?

 

[Wildcard]

- wie sieht denn die EMF unterstützung außerhalb von eclipse aus?

EMF ist Standalone und wird häufig Standalone eingesetzt. Für Eclipse gibt es nur noch zusätzliche Funktionalitäten wie automatisch generierte CRUD Editoren, Support für Diagramme, spezielle Eclipse Projekt-basierte URI resolution, grafische Compare Editoren und allerlei Spielereien. Bestimmte Dinge wie Tree/Table/List Unterstützung, Automatisches Undo/Redo, Databinding, Transaktionen,... sind prinzipiell Eclipse unabhängig implementiert, funktionieren aber nur in Eclipse komplett ohne Eigenleistung. Mit anderen Worten, für bestimmte Funktionalitäten muss man einen eigenen Swing/Qt/GWT/... Adapter bereitstellen weil EMF nur eine SWT Variante implementiert

- gibt support für maven/ant?

Ja, ist aber eigentlich nicht nötig. EMF Code ist die Art Code die man normal eincheckt weil man ihn händisch Aufbohrt. Zusätzliche Methoden, derrived features, Business Logik, Invarianten,...
Es gibt auch Fälle in denen man den Code tatsächlich gar nicht erweitert. Dann hat man Klassen die zwar mehr können als JAXB Klassen (Erweiterbarkeit, Adaptierbarkeit, erweiterte Reflection/Introspection, Listener, explizites Containment, Opposites, Feature Maps,...), aber im Herzen sind es immer noch Beans. In diesen Fällen braucht man oft gar keinen Code generieren und verwendet stattdessen dynamic Ecore. Dynamic Ecore kann man sich wie stark aufgebohrte Java Reflection vorstellen und dynamische Ecore Modelle verfügen über die gleichen Fähigkeiten wie statisch kompilierte Klassen aber natürlich ohne Code Customizing.

- wieviele dependencies hole ich mir denn durch emf rein?

EMF ist sehr modular und es gibt dutzende Erweiterungen. Hängt also davon ab was man mit dem Modell alles machen will. Für die Standardfunktionalität + XMI und XML sind das AFAIR 3 jars. (Ist auch auf Maven Central erhältlich). Wenn es dir um kB geht muss ich passen, das musst du selbst zusammen zählen.

- generiert man die klassen wie bei jaxb auch immer und immer wieder (würde bedeuten, dass das graphische(?) Modell "master" ist, ähnlich dem xml schema bei jaxb)?

Die Idee bei EMF ist immer Round Trip Engineering. Der 'Hub' ist Ecore (siehe OMG EMOF).
Ein Ecore kann aus verschiedenen Quellen erzeugt werden, ich nenne hier nur ein paar davon:

• Rational Rose
• Annotierte Java Interfaces
• Baumeditor
• UML-like Ecore Editor
• UML
• verschiedene DSLs
• XML Schema

Hast du eines davon, lassen sich alle anderen wieder daraus ableiten.
Du kannst also zb ein UML Diagramm erzeugen, daraus ein Ecore erstellen und aus dem Ecore dann ein XML Schema. Anschließend löschst du das Schema, erzeugst das Ecore aus dem Schema und bekommst wieder das gleiche Ergebnis.
Ähnlich verhält es sich auch für die Persistenz der Modelle. Das gleiche Modell kann per XML, binär, textuell, in einer Datenbank, oder sonstwie gespeichert werden, das Modell ist davon unabhängig.
So versteht man auch wie der Round Trip bei Ecore funktioniert, denn ein Ecore ist ein EMF Modell über EMF Modelle. XSD ist eine mögliche Persistenzschicht für ein Ecore genau wie Annotierte Java Interfaces, oder UML. Die enthaltene Information bleibt dabei die selbe.
In der Praxis ist es so das sich ein Team normalerweise für einen Weg entscheidet. Wir stellen das Ecore in den Mittelpunkt, arbeiten also immer erst am Ecore und regenerieren dann den Java Code. Andere Teams machen es andersherum, oder arbeiten zB XML Schema driven.
Ich halte nicht viel davon die Klassen immer wieder beim Build zu generieren, denn bei uns sind die EMF Klassen first-class citizens. Werden erweitert, dokumentiert, refactored, getested und committed. Andere Teams halten das anders und das ist auch ok.
Das funktioniert deshalb, weil der EMF Code generator merging Logik beinhaltet. Alles generierte wird durch annotations gegenzeichnet (@generated). Änderst du eine generierte Methode änderst du das @generated zu @generated NOT. Wenn du neue Methoden einfügen willst, tust du das einfach. Wenn sich irgendwann das Modell ändert und du neu generierst, dann werden die händischen Änderungen mit den generierten gemerged. Also was mit @generated markiert ist, wird bei Bedarf neu geschrieben, alles ohne diese Annotation, oder mit @generated NOT wird in Ruhe gelassen.
Es gibt auch noch Zwischenstufen, also anstatt eine Methode mit @generated NOT zu markieren und händisch zu implementieren, die generierte Funktionalität bestehen zu lassen und um händische Funktionalität zu erweitern, aber ich denke das führt jetzt zu weit.
Wenn man Eclipse als IDE verwendet gibt es auch Tooling Support für das ganze. Zum Beispiel wird in der Outline farbig hervorgehoben welche Methoden generiert und welche customized sind und ein neues Kontextmenü 'customize EMF generated method' usw.
Das Tool passt sich deinem Workflow an, nicht umgekehrt und das finde ich auch wichtig.

 

[musiKk]

Ja, ist aber eigentlich nicht nötig. EMF Code ist die Art Code die man normal eincheckt weil man ihn händisch Aufbohrt.

Ich halte das schon für wichtig. Ich bin generell immer dafür, eher die Quellen von was-auch-immer einzuchecken, als das Resultat (z. B. tex, DocBook statt PDF und eben auch XSD statt Klassen). Sonst müssen sich die Entwickler ja die Quellen selbst austauschen und immer up-to-date halten (in diesem Fall wohl das ecore Model).

Vielleicht trifft das auf diesen dynamischen Modus nicht zu, von dem habe ich noch nicht gehört.

 

[mvitz]

Ich denke eher, es wird dann beides eingecheckt.

 

[Wildcard]

Ich denke eher, es wird dann beides eingecheckt.

Ja, Ecore und Code werden normal eingecheckt. Wer den Code immer beim Build generieren möchte checked nur das Ecore (oder Schema, oder sonstwas) ein.