[Edapt] DiagnosticException while migrating [message #1767030] |
Thu, 29 June 2017 17:21 |
Martin Jacob Messages: 191 Registered: July 2009 |
Senior Member |
|
|
Hi all,
I am looking for help to sovle a DiagnosticException while migrating the first time my existing ecode model files to a new version.
I had already an ecore model before starting with edapt. I need to change my ecore model and would like to use edapt to automatic migrate from the existing ecore model to the new model.
Following the documentation I need to create a initial "history" from the existing model, then do my modification and create a release. All I have done but when I invoke the migration code I get a DiagnosticException which I can not interpret.
org.eclipse.emf.edapt.migration.MigrationException: org.eclipse.emf.edapt.internal.migration.DiagnosticException: Model inconsistent
The 'validContainment' constraint is violated on 'Instance of type "Railml"'
The 'validContainment' constraint is violated on 'Instance of type "EStringToStringMapEntry"'
The 'validContainment' constraint is violated on 'Instance of type "EStringToStringMapEntry"'
My ecore model was generated from a xsd and has a DocumentRoot class, I belive it has some thing todo with it but cant figure out what to do.
Attached you can find the ecore and history file as well as the file I need to upgrade.
Any help is appreciated!
Martin
PS: I am using Eclipse 4.6 IDE with edapt record feature 1.2.2 while my target edapt version is still 1.2.1
[Updated on: Fri, 30 June 2017 14:06] Report message to a moderator
|
|
|
|
|
Re: [Edapt] DiagnosticException while migrating [message #1767183 is a reply to message #1767087] |
Mon, 03 July 2017 09:53 |
|
Hi,
thanks for the additional files. I managed to get a bit further, however I can still not reproduce your issue.
Loading of your provided file fails for me, because the rollingstockID feature can't be found. I can't see references in the ecore or history as well.
Probably there is custom stuff going on with the serialization?
Just as a hint, it is possible to provide the right resource/resourceset for loading the file with the
org.eclipse.emf.edapt.migration.execution.Migrator.setResourceSetFactory(IResourceSetFactory)
method.
Currently I can't see why not being contained in a DocumentRoot could cause this. Unless a document root is somehow created on the run by custom de/serialization code. Maybe a runnable example would help.
In the code you posted, it would be interesting to know why it is not valid, so how many containers/resources are there? What and how many root instances are there?
Regards
Johannes
Johannes Faltermeier
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
|
Re: [Edapt] DiagnosticException while migrating [message #1767196 is a reply to message #1767183] |
Mon, 03 July 2017 12:54 |
Martin Jacob Messages: 191 Registered: July 2009 |
Senior Member |
|
|
Hi Johannes,
thanks for your feedback.
Oh yah there are some additional attribues from an much earlier implementation. These are ignored by seeting XMLResource.OPTION_RECORD_UNKNOWN_FEATUR to true
package de.bahntechnik.dd.opn.engine.util;
/**
* Creates an instance of the resource. <!-- begin-user-doc --> <!--
* end-user-doc -->
*
* @generated NOT
*/
@Override
public Resource createResource(URI uri) {
XMLResource result = (XMLResource) createResourceGen(uri);
result.getDefaultSaveOptions()
.put(XMLResource.OPTION_KEEP_DEFAULT_CONTENT, Boolean.TRUE);
result.getDefaultLoadOptions()
.put(XMLResource.OPTION_RECORD_UNKNOWN_FEATURE, Boolean.TRUE);
return result;
}
/**
* Creates an instance of the resource. <!-- begin-user-doc --> <!--
* end-user-doc -->
*
* @generated
*/
public Resource createResourceGen(URI uri) {
XMLResource result = new OpnengineResourceImpl(uri);
result.getDefaultSaveOptions()
.put(XMLResource.OPTION_EXTENDED_META_DATA, Boolean.TRUE);
result.getDefaultLoadOptions()
.put(XMLResource.OPTION_EXTENDED_META_DATA, Boolean.TRUE);
result.getDefaultSaveOptions().put(XMLResource.OPTION_SCHEMA_LOCATION,
Boolean.TRUE);
result.getDefaultLoadOptions().put(
XMLResource.OPTION_USE_ENCODED_ATTRIBUTE_STYLE, Boolean.TRUE);
result.getDefaultSaveOptions().put(
XMLResource.OPTION_USE_ENCODED_ATTRIBUTE_STYLE, Boolean.TRUE);
result.getDefaultLoadOptions()
.put(XMLResource.OPTION_USE_LEXICAL_HANDLER, Boolean.TRUE);
return result;
}
Regarding the validate_validContainment.
instance is "Instance of Railml"
container == 0
resources == 0
final boolean valid = container == 1 && resources <= 1 || resources == 1 && container <= 1;
I belive this is because the root of the EMF model is DocumentRoot and the root of the XML is <railml>.
We do not use a own ResourceSetFactory or ResourceSet implementation.
We currently try to remove the DocumentRoot from our EMF model but this is not jet finished. As we need to make sure we still can read existing files withour problem.
thanks for your thoughts, Martin
|
|
|
Re: [Edapt] DiagnosticException while migrating [message #1767267 is a reply to message #1767196] |
Tue, 04 July 2017 11:39 |
|
Hi Martin,
this works and now I get it. The XMLResource itself is creating the DocumentRoot and thus is causing the problem. So yes, you are right.
You can suppress this with
resource.getDefaultLoadOptions().put(XMIResource.OPTION_SUPPRESS_DOCUMENT_ROOT, Boolean.TRUE);
If you can't add this to your actuall Resource(Factory)Implementation you can use above mentioned #setResourceSetFactory method to use a slightly adjusted resource factory.
migrator.setResourceSetFactory(new IResourceSetFactory() {
@Override
public ResourceSet createResourceSet() {
MyCustomResourceSetFactoryForMigrytion factory = new MyCustomResourceSetFactoryForMigrytion(); //this add the additional load option
ResourceSetImpl resourceSetImpl = new ResourceSetImpl();
resourceSetImpl.getResourceFactoryRegistry().getExtensionToFactoryMap().put("*", factory);
return resourceSetImpl;
}
});
Hope this helps
Johannes
Johannes Faltermeier
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04340 seconds