EMF for Starters...

[dzim]

Hallo an alle,

ich hab mich lang davor gedrückt, aber nun will ich es wagen und mich mal ernsthaft mit EMF auseinandersetzen.

Ich hab jetzt bereits mehrere Ansätze mal ausprobiert:
* mittels einer ecore-Datei - hier finde ich aber das Handling und den Aufbau des Modells über den vorhandenen Editor eher düftig
* XML Schema - ganz nett, weil wir bereits viele haben, aber: Paketstrukturen sehen jedenfalls in meinem Beispiel eher Bescheiden aus
* UML-Diagramm - finde ich noch am sinnvollsten, leider hab ich mich schon lange (!) nicht mehr mit UML beschäftigt.

Was denkt ihr, ist der beste Ansatz?

Ich habe allerdings noch eine Fragen:
1) Export: wir haben mit einem Kunden nur eine XML-Schnittstelle, also interessiert sie im Endeffekt nur das Schema. Das kann man doch sicher irgendwie über das genmodel exportieren, oder? Wie sieht das aus? kann man da "hoffen", dass es jedes mal ungefähr gleich aussieht und nur die tatsächlichen Änderungen die Struktur beeinflussen?
2) Persistenz: ich habe bisher - auch nicht mit dem Tutorial von Lars Vogel - wirklich verstanden, wie man, wenn man das Modell im Java-Umfeld tatsächlich verwendet, es persistiert (und wieder liest) und als was das dort abgespeichert wird. (Anscheinend landet es im o.g. Beispiel in einer Datei über die dort angegebene URI, aber wirklich gerafft hab ich das nicht)
2.1) Wie kann man, ausser es dann über ein DAO oder so zu jagen, verschiedene Persistierungsarten vornehmen (XML, DB, ...)

Ich hoffe, das waren jetzt nicht alles DAU-Fragen, aber ich stelle sie aus gutem Grund: Wir kamen gestern mit der Idee, dass man ja für ein Produkt vielleicht ein GMF-Editor anbieten könnte und AFAIK braucht man dazu zwingend ein EMF...

Danke schon mal!
Daniel

 

[dzim]

Noch eine Frage hintenan:
Welche Extensions benötige ich eigentlich in meiner plugin.xml?
War das org.eclipse.emf.ecore.generated_package? War da nicht noch eine zweite? Ich hab das in meinem Testprojekt nach dem ersten Mal generieren wieder gelöscht... (Ich Esel ich!)

 

[dzim]

Ok, ich hab eingesehen, das meine UML-Kentnisse Kurzfristig zu eingestaubt sind, ich werde daher am besten mit dem Anfangen, was ich kann und ein Schema nutzen. Ist zwar ein wenig dämlich, ein Schema zu bauen, es zu übersetzen und wieder ein korrigiertes Schema oder so zu erstellen. Und mein Problem mit den Packeten bleibt bestehen.

Gibt es einen Weg ein ordentliches Schema zu bauen und gleichzeitig vernünftige Packetstrukturen zu erstellen, die nicht gleich dem Namespace des Schemas sind?

 

[Wildcard]

* mittels einer ecore-Datei - hier finde ich aber das Handling und den Aufbau des Modells über den vorhandenen Editor eher düftig

Sehe ich anders. Der Baumeditor lässt dich alle Informationen einstellen. Ausserdem kannst du auf Knopfdruck auch ein Diagramm dafür erstellen und mit dem Diagramm arbeiten wenn dir das mehr liegt.

1) Export: wir haben mit einem Kunden nur eine XML-Schnittstelle, also interessiert sie im Endeffekt nur das Schema. Das kann man doch sicher irgendwie über das genmodel exportieren, oder? Wie sieht das aus? kann man da "hoffen", dass es jedes mal ungefähr gleich aussieht und nur die tatsächlichen Änderungen die Struktur beeinflussen?

Im Wizard gibt es eine 'generate XML Schema' oder so Checkbox.

2) Persistenz: ich habe bisher - auch nicht mit dem Tutorial von Lars Vogel - wirklich verstanden, wie man, wenn man das Modell im Java-Umfeld tatsächlich verwendet, es persistiert (und wieder liest) und als was das dort abgespeichert wird. (Anscheinend landet es im o.g. Beispiel in einer Datei über die dort angegebene URI, aber wirklich gerafft hab ich das nicht)

Man liest und speichert über die Resource. Rufst du einfach save auf, dann entscheidet die URI wo das Ding landet. Du kannst aber auch in einen Outputstream schreiben und von einem InputStream laden.
Solange du dich in Eclipse bewegst und Eclipse Resources verwendest sind die URIs völlig ausreichend (lassen sich direkt aus einem eclipse IPath erzeugen).

2.1) Wie kann man, ausser es dann über ein DAO oder so zu jagen, verschiedene Persistierungsarten vornehmen (XML, DB, ...)

Grundsätzlich entscheidet die Resource. Es gibt die Build-in XML und XMI Resources, textuelle Resources (XText) und diverse Varianten für Datenbank, Modell Repository, Java Content Repository,...
Wichtige Stichworte hierfür: CDO, Teneo, EclipseLink.
CDO ist ein extrem mächtiges Framework für Model-Repositories und für extrem große Modelle und viele Clients geeignet. Teneo bietet EMF Bindings für wahlweise Hibernate oder EclipseLink.
Schau dir beide mal an, welches besser passt hängt von deinen Anforderungen ab. Beide sind subprojekte von EMF.

Welche Extensions benötige ich eigentlich in meiner plugin.xml?
War das org.eclipse.emf.ecore.generated_package? War da nicht noch eine zweite? Ich hab das in meinem Testprojekt nach dem ersten Mal generieren wieder gelöscht... (Ich Esel ich!)

Du benötigst nicht zwingend eine Extension und du benötigst auch kein Eclipse. Die Extensions sind dazu da dein EMF Package automatisch an einen bestimmten Namespace und, oder Dateiendung zu koppeln.

Gibt es einen Weg ein ordentliches Schema zu bauen und gleichzeitig vernünftige Packetstrukturen zu erstellen, die nicht gleich dem Namespace des Schemas sind?

Die packages müssen nicht zwingend mit dem Namespace übereinstimmen, das ist lediglich ein Default-Wert. Du kannst sehr feingranular Steuern wie Elemente in XML übersetzt werden.
Den Schema weg würde ich allerdings nur gehen wenn das Schema schon vorher da ist. Ansonsten lieber den Editor, UML, oder annotierte Interfaces verwenden, das ist zumindest meine Meinung.
Es gibt auch eine textuelle Syntax um EMF Modelle zu beschreiben falls dir das besser liegt.
Der Editor mag optisch nicht viel hermachen, aber ich würde ihm noch eine Chance geben, denn er erfüllt seine Aufgabe IMO gut.

 

[dzim]

Danke für die ausführliche Antwort erst einmal!
Ich werde dem Editor noch einmal eine Chance geben und damit arbeiten, ansonten werde ich wohl den Weg über die annotierten Java-Interfaces gehen, auch wenn ich diese Annotation innerhalb von JavaDoc etwas unintuitiv finde, sehe ich doch so am ehesten, was am Ende entstehen soll.

Du benötigst nicht zwingend eine Extension und du benötigst auch kein Eclipse. Die Extensions sind dazu da dein EMF Package automatisch an einen bestimmten Namespace und, oder Dateiendung zu koppeln.

Ok, dann werde ich es wohl auch erst einmal ohne diese Extensions machen!

Da ich im konkreten erst einmal mit XMLs als Persistenzebene arbeiten werde, werde ich auf die anderen von dir genannten Mittel später zurück kommen.
Wir verwenden seit kurzem (wenn auch noch experimentell) EclipseLink für unsere DB-Anbindung, also wird später Teneo sicher noch einmal in den Fokus rücken! Danke für diese Information!

Im Wizard gibt es eine 'generate XML Schema' oder so Checkbox.

Ja, den hab ich mittleriweile gefunden.

 

[dzim]

Ich hab heute mal begonnen eines unserer kleineren Schemas (est ist wirklich recht niedlich, hat aber immerhin ein paar Vererbungen, abstracts u.s.w drin)

Ich wollte ein Attribut erstellen, das eine Enum ist, hab dann aber nach einer weile begriffen, das es am einfachsten ist eine eigene zu definieren und dann als typ an das Attribut zu hängen, da ich ansonsten beim Typ EEnumeration keine konkreten Werte eingeben konnte (oder ich hab es jedenfalls nicht gesehen)

Ich wollte jetzt das ganze in ein genmodel übertragen um dann damit weiter zu spielen, dabei bin ich aber auf folgendes keline Problem gestoßen (also für mich war es ein Problem):

ich habe eine Paket-Struktur erstellt, die sich hierarchisch von com... bis ...configuration durchhangelt. Beim Erstellen des genmodels bekam ich folgende Fehler

The namespace URI '' is not well formed
The namespace URI 'null' is not well formed
The namespace prefix '' is not well formed

Wobei der obere Fehler nur ein mal, die anderen aber ansacheinend so oft, wie ich packete habe, aufgetreten sind.
Muss ich zu jedem Package eine uri und ein Prefix angeben? Muss das dann jedes Mal anders aussehen?

edit: wenn ich jetzt einmal trotz der Fehler weiter im wizard klicke, bekomme ich als package auch nur das oberste angezeigt - kann man denn auch komplette package-Namen angeben?

 

[Wildcard]

Hat dein Schema eventuell keinen Targetnamespace?

 

[dzim]

Ja, ich hatte keinen Target-Namespace. Hab ich jetzt eingetragen.
Muss ich jetzt jedem package und sub-package einen namespace geben?

Wenn ich es dann exportiere (also das genmodel daraus mache und dann daraus ein XML Schema exportiere), wird jede Klasse als Top-Level-Element verwendet - also irgendwas stimmt da noch nicht so ganz.

 

[Wildcard]

Ja, ich hatte keinen Target-Namespace. Hab ich jetzt eingetragen.
Muss ich jetzt jedem package und sub-package einen namespace geben?

Du meinst ePackages? Davon hast du in der Regel nicht viele, viele Anwendungen haben wohl nur ein einziges.

Wenn ich es dann exportiere (also das genmodel daraus mache und dann daraus ein XML Schema exportiere), wird jede Klasse als Top-Level-Element verwendet - also irgendwas stimmt da noch nicht so ganz.

XML Schema gibt kein Root vor, nur Typ und Element Definitionen. Jedes Element und jeder Typ eines XSDs kann zum Root einer XML Instanz werden.

 

[dzim]

Ok, dann hab ich da wohl noch etwas falsch verstanden.
Ich hatte jetzt die komplette packetstructur nachgebebaut - also wie oben kurz beschrieben. Und unsere Package-Struktur ist recht groß.

Ein Beispiel:
javax.xml.transform - da hätte ich jetzt so was wie javax als Toplevel-Eintrag (ePackage) im ecore, dann ein Sub-Package xml und noch eines darunter mit transform.

Bei uns wären die eigentlichen Daten irgendwo in der 7ten (!) Ebene... (Das ist mittlerweile echt schon nicht mehr feierlich, aber nun auch nicht mehr zu ändern...)

Das mit dem Top-Level-Element im Schema hab ich natürlich etwas falsch ausgedrückt! Wenn ich ein Schema baue, lege ich ein Element (oder so viel wie ich im Top-Level eben benötige) an und realisiere den Rest über complexType (also alle weiteren Elemente darunter). Vermutlich kann man so was aber nicht im eCore festlegen, was?

 

[dzim]

Worüber ich mich vor allem gerade wundere, ist folgendes:
Warum kann ich dem package nicht einfach einen Namen á la javax.xml.transform geben??? Da kommt immer ein "namespace URI not wellformed" oder so, wenn ich es ins genmodel überführen will. Ich versteh nicht, warum das nicht zugelassen ist. Ich denke mal, das im normalen Umfeld doch Paketstrukturen immer etwas größere Hirarchieebenen aufweisen, als eine oder zwei.

 

[Wildcard]

Ebenen (die es bei Packages eigentlich gar nicht gibt), kannst du beliebig viele einführen. Allerdings ist der Namespace eine URI und javax.xml.transform ist keine gültige URI. Nimm so etwas wie Org.com - Only the best links .... Daraus wird dann beim Code generieren eine Java Package Struktur inferiert.

Das mit dem Top-Level-Element im Schema hab ich natürlich etwas falsch ausgedrückt! Wenn ich ein Schema baue, lege ich ein Element (oder so viel wie ich im Top-Level eben benötige) an und realisiere den Rest über complexType (also alle weiteren Elemente darunter). Vermutlich kann man so was aber nicht im eCore festlegen, was?

Nun, das ist deine Art das zu tun, dafür gibt es keine allgemeinen Richtlinien. Wenn du unbedingt ein speziell formatiertes Schema erwartest, würde ich nicht das Modell schreiben und dann das Schema generieren lassen, sondern das Schema schreiben und daraus das Modell generieren.
Das generierte Ecore kannst du dann trotzdem noch anpassen/erweitern.

 

[dzim]

javax.xml.transform war auch nur als Beispiel für eine Paketstruktur gedacht.
Ich habe es im Test-ecore jetzt so umgesetzt, das nur die Packete, die wirklich mal verwendet werden eine vernünftige URI bekommen, die anderen bekommer mehr oder weniger nur einen eindeutigen "dummy".

Ich weiß, dass du den ecore-Editor recht gut findest, aber ich finde auch den Schema-Editor sehr gut und ziehe von daher diesen vor. Als Nachteilhaft hat sich aber herausgestellt, das unsere NamspaceURI-Konvention nicht unbedingt die tatsächliche Paketstruktur wiederspiegeln muss. Als Beispiel:

http://www.my-company.com/my-project/schema/my-purpose/0.1

Ausser in "my-purpose" kommen nirgens Bindestriche vor. Erstellt man aus einem solchen Schema ein ecore, wird die Paketstruktur wie folgt generiert:

com.my-company.my-project.schema.my.purpose._0

Das spiegelt halt nichts gültiges wieder (für uns) - kann man das irgendwie mappen?

edit: klar kann man das erzeugte ecore sicher noch anpassen, aber man will ja alles nur über ein Schema/ecore/uml oder anpassen und nicht dann hinterher noch wahnsinnig viel andere Anpassungen vornehmen müssen...

 

[Wildcard]

Öffne das Ecore im Editor. Dort hast du für das ePackage folgende Attribute:
Name: Der Name deines Modells. Der Name wird als Suffix an das Base Package angehängt.
NS Prefix: bei XML bestimmt das den NS Prefix bei der serialisierung
NS URI: sollte dem Target Namespace deines Schemas entsprechen

Anschließend öffnest du das Genmodel und selektierst das ePackage. Dort kannst du nun ein base package eintragen. Anschließend werden folgende Packages generiert:
$basepackage.$packagename
$basepackage.$packagename.impl
$basepackage.$packagename.util

Die Suffixe impl, util usw lassen sich ebenfalls über das genmodel anpassen.
Das Ecore bestimmt wie dein Modell aufgebaut ist, das genmodel steuert die Codegenerierung.