[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.tools.emf] Re: Model Migration 
Hi Ed

Your scenario looks different. You appear to have both models as generated models (right?) whereas in the recipe only the final model is generated so for the old model in the recipe the dynamic model will be used.

Yes you're right. But now I've tried setting things up like in the recipe. I've closed the project, that declares the generated_package extension point for the old model, so there's no way any more mapping the NS URI used in to-be-migrated files to the old model's package. Thus, the generated model cannot be contacted and a dynamic model should be generated with the assistance of the configured ExtendedMetaData while deserializing, right?

The loading of an old-model-resource still works with this approach, immediately saving after load does too, but the model is still serialized in the old format.

I'm close to going crazy :)

I think you need a mapping like this so that the physical serialized source .ecore to which your .ecore2xml refers is redirected to the actual generated static instance that's used to load your original source model:

ePackageRegistry.put(SOURCE_ECORE, UiPackage.eINSTANCE);

I've tried this before going the dynamic-model way like described above, but without luck.



Ömer Yildiz wrote:
Well, no matter what I do, nothing affects the serialization. I stepped through the code a bit... Ecore2XMLExtendedMetaData is definitely used to load/save the resource, but the output is always the old model version.

The code is essentially the same as written in the recipe:

"UiPackage" is the *old* model.
"UIModelPackage" is the *new* model.

"TARGET_ECORE" points to the *new* model's .ecore file
"MODEL_MAPPING" points to the .ecore2xml file

public Resource createResource(URI uri) {
  ...
  defaultLoadOptions.put(XMLResource.OPTION_EXTENDED_META_DATA,
     getExtendedMetaData());
  ...
  resource.getDefaultSaveOptions().put(
     XMLResource.OPTION_EXTENDED_META_DATA, Boolean.TRUE);
}

private ExtendedMetaData getExtendedMetaData() {
...
rs.getPackageRegistry().put(UiPackage.eNS_URI,
UIModelPackage.eINSTANCE);
rs.getPackageRegistry().put(TARGET_ECORE, UIModelPackage.eINSTANCE);

  ...
  ecore2xmlRegistry.put(UiPackage.eNS_URI, EcoreUtil
     .getObjectByType(rs.getResource(
        URI.createURI(MODEL_MAPPING),true).getContents(),
        Ecore2XMLPackage.Literals.XML_MAP));

  ...
}


Ed Merks schrieb: 
Ömer,

It sounds to me like this is liable to do the reverse mapping. What happens if you don't do that? You can use this option mapped to Boolean.TRUE for save if you need the option to produce a schema-conforming serialization...


Ömer Yildiz wrote:
I forgot to mention, that I've already set the same value for OPTION_EXTENDED_META_DATA in the default save options.


Ömer Yildiz schrieb: 
Hello,

i've tried to migrate an older version of my model using your recipe, but without success. After loading the instance of an old model, I immediately called resource.save(), assuming that EMF would serialize it using the newer version of my model.

Any hints?

Best regards,
Ömer yildiz

Mike Gering schrieb: 
Ed,

Thanks for prompt and excellent advice, as always!

Here is a revised code fragment:

public class RulesResourceFactoryImpl extends XMIResourceFactoryImpl {

public static final String RULES_100_NS_URI = "http://www.ibm.com/vce/1.0.0/rules";;
public static final String RULES_PLATFORM_URI = "platform:/plugin/com.ibm.adt.vce.rules.model/model/Rules.ecore";
public static final String RULES_100_PLATFORM_URI = "platform:/plugin/com.ibm.adt.vce.rules.model/model/Rules100_2_Rules.ecore2xml";


private ExtendedMetaData extendedMetaData;
/* (non-Javadoc)
* @see org.eclipse.emf.ecore.resource.impl.ResourceFactoryImpl#createResource(org.eclipse.emf.common.util.URI)

*/
public Resource createResource(URI uri) {
XMIResource resource = (XMIResource) super.createResource(uri);

Map defaultLoadOptions = resource.getDefaultLoadOptions();
defaultLoadOptions.put(XMLResource.OPTION_EXTENDED_META_DATA,
getExtendedMetaData());
defaultLoadOptions.put(XMLResource.OPTION_RECORD_UNKNOWN_FEATURE,
Boolean.TRUE);
defaultLoadOptions.put(XMLResource.OPTION_RESOURCE_HANDLER,
new RulesResourceHandler());
return resource;
}

private ExtendedMetaData getExtendedMetaData() {
if(extendedMetaData == null) {
ResourceSet resourceSet = new ResourceSetImpl();
EPackage.Registry ePackageRegistry = resourceSet.getPackageRegistry();
ePackageRegistry.put(RULES_100_NS_URI, RulesPackage.eINSTANCE);
ePackageRegistry.put(RULES_PLATFORM_URI, RulesPackage.eINSTANCE);
resourceSet.setPackageRegistry(ePackageRegistry);
Ecore2XMLRegistry ecore2xmlRegistry = new Ecore2XMLRegistryImpl(Ecore2XMLRegistry.INSTANCE);
ecore2xmlRegistry.put(RULES_100_NS_URI,
EcoreUtil.getObjectByType(
resourceSet.getResource(URI.createURI(RULES_100_PLATFORM_URI),
true).getContents(),
Ecore2XMLPackage.Literals.XML_MAP));
extendedMetaData = new Ecore2XMLExtendedMetaData(EPackage.Registry.INSTANCE, ecore2xmlRegistry); }
return extendedMetaData;
}
}

If this passes muster, I can consider making a recipe of it. I found it
distressingly hard to get this far by reading the various newsgroup articles and
the EclipseCon 2006 slides.

Thanks again,
Mike