Known issues (updated 13 September 2006)
From 13 September 2006: for open issues please visit the EMF open bugs page.
This page describes known issues (and possible work arounds) and gives an estimate on when they will be solved.
Open issue(s):
- Objects are not loaded in the resource, or the resource is empty: The standard behavior of a Jpox resource is to only read types which have no container in the model. All other EObjects can be reached from these top-entities. However, this means that even if an EObject instance does not have a container but can be contained according to the model then it will still not be loaded in the resource. A common model is a an object which contains itself, for example a folder-like model. Workaround: to workaround this issue you should load the resource using specific queries, see customizing load behavior here.
The following issue has been solved in the 0.7.1 release:
- Generated package.jdo not visible: after choosing the Elver menu option to generate a package.jdo the folder is not refreshed so the generated package.jdo file is not visible. Will be solved in the next release.
The following issue has been solved in the 0.7.0 release:
- Java Annotations to Ecore, mapping file error: When starting the runtime the following error
message is displayed (using the Library example):Association references unmapped class: Book.
The issue is related to the fact that the model is generated from annotated java. Currently Elver uses the annotations in the source code to resolve java types. The java sources generated from the uml/xml schema have fully quallified names in the type attribute of the model tag:
* @model type="org.eclipse.example.library.Writer" * @generated */ EList getWriters();
While in the case the java annotations are the input the emf tutorial tells you to do this:
/** * @model type="Writer" containment="true" */ List getWriters();
Elver should automatically resolve the Writer to a org.eclipse.example.library.Writer interface but does not do this. As a workaround you should specify the fully qualified class name in the type annotation.
The following issues have been solved in the 0.6.5 release:
- Load notification on EList load has been disabled.. After an elist/featuremap is loaded a notification is sent out. See here for more information. Apparently this notification results in exceptions and double entries in rich client tree viewers. See the posts on the mailing list for this: post 1, post 2. As a workaround you should 'catch' the notification in the notifychanged of the EObjects ItemProvider. This will be solved in the next release or the function will be disabled until it is more stable.
Previous issues have been solved or a workaround or description is displayed on the troubleshooting page.