Comment 1 Moritz Eysholdt 2011-06-01 05:50:30 EDT

could you please try the following steps:

1. open the genmodel in EMF's genmodel-editor and run "reload" from the context menu. Walk through all of the wizards steps.

2. In the context menu of the genmodel's root-node, run "validate". Make sure no errors are found.

If you still get the error, can you please attach your *.mwe file, the grammar, and all invoved *.genmodels and *.ecore models.

Furthermore, could you use org.eclipse.emf.mwe.utils.StandaloneSetup.addRegisterGenModelFile(String) instead of EcoreGeneratorFragment.referencedGenModels?

I assume this error is cause by unresolved proxies. Maybe we should validate for this before the GenModel is registered. I've been running in similar NPEs myself before and they're not very helpful at all to find the error's cause.

Comment 2 Christophe Bouhier 2011-06-01 07:37:41 EDT

> 1. open the genmodel in EMF's genmodel-editor and run "reload" from the context
> menu. Walk through all of the wizards steps.
reload occurs without errors or warnings. The model is valid and in use for som time, I should mention is based on .xsd, so many of the primitive types are XML types. It consists of many different .xsd files which are referenced and imported. I also use a CDO version of the model which loads without problems in the CDO repository. 

> 2. In the context menu of the genmodel's root-node, run "validate". Make sure
> no errors are found.
mmh, I am frequent user of EMF, but I notice now the validate action is not available in the popup menu. 
> 
> If you still get the error, can you please attach your *.mwe file, the grammar,
> and all invoved *.genmodels and *.ecore models.
> 
The error is easily reproducable. I will attach the models to this bug and the mwe2 file. 

> Furthermore, could you use
> org.eclipse.emf.mwe.utils.StandaloneSetup.addRegisterGenModelFile(String)
> instead of EcoreGeneratorFragment.referencedGenModels?
>
 Ok, will try. 

> I assume this error is cause by unresolved proxies. Maybe we should validate
> for this before the GenModel is registered. I've been running in similar NPEs
> myself before and they're not very helpful at all to find the error's cause.
yep, not usefull NPE.

Comment 3 Christophe Bouhier 2011-06-01 07:40:20 EDT

Created attachment 197084 [details]
zip file with model.

zip file with complete model.

Comment 4 Christophe Bouhier 2011-06-01 07:45:34 EDT

Created attachment 197085 [details]
workflow file.

Comment 5 Christophe Bouhier 2011-06-11 04:53:26 EDT

Hi Moritz, 

I still get this problem, with the attached model.  I have now referenced the .genmodel as this in .mwe2

bean = StandaloneSetup {
        scanClassPath = true
        platformUri = "${runtimeProject}/.."
        registerGenModelFile = "platform:/resource/com.netxforge.netxstudio.models/models/emf/13042011/netxstudio.genmodel"
    }


It could this be a problem, in which the .genmodel is processed, as I have many EPackage definitions? 
So the order in which the EPackages appear in the .genmodel? 

 Christophe

Comment 6 Christophe Bouhier 2011-06-11 05:05:41 EDT

Mortiz,  I also need to mention this model is based on .xsd, and there for some types are XML types like this one in generics.ecore: "ecore:EDataType http://www.eclipse.org/emf/2003/XMLType#//DateTime"

Can xtext deal with these types of models? Can you reproduce on your end? 

<eStructuralFeatures xsi:type="ecore:EAttribute" name="begin" eType="ecore:EDataType http://www.eclipse.org/emf/2003/XMLType#//DateTime">
      <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
        <details key="documentation" value="The Begin attribute holds the starting date time of the range."/>
      </eAnnotations>
      <eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
        <details key="kind" value="attribute"/>
        <details key="name" value="Begin"/>
      </eAnnotations>
    </eStructuralFeatures>

Comment 7 Christophe Bouhier 2011-06-11 08:40:10 EDT

Hi, 

I debugged the problem, and tracked it down to a proxy URI reference to the ecore EPackage (Which wasn't really needed). The method (GenModelHelper), genModel.getUsedGenPackages. returns a GenPackage with an empty ecorePackage field, with method  EPackage getEcorePackage() returning null. 

Further on in registerGenModel() line 64 String nsURI = pkg.getEcorePackage().getNsURI(); causes the null exception. 

I worked around this, by removing the ecore EPackage which appeared in my .genmodel as: 

usedGenPackages="platform:/plugin/org.eclipse.emf.ecore/model/Ecore.genmodel#//ecore"

Comment 8 Samantha Chan 2011-06-21 19:52:50 EDT

I am hitting this error too... :(

Comment 9 Sebastian Zarnekow 2011-06-22 02:10:01 EDT

Possible Workaround: register an uri mapping from platfrom:/resource/.../model/Ecore.ecore to its http URI in the standalone setup of the workflow

Comment 10 steven reinisch 2011-08-08 12:43:24 EDT

I had to replace 'platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#' with 'http://www.eclipse.org/emf/2002/Ecore#' in all my .ecore files to work around the NPE.

Comment 11 Sebastian Zarnekow 2011-11-09 14:46:15 EST

Will investigate for 2.1.1

Comment 12 Sebastian Zarnekow 2011-11-10 05:53:21 EST

(In reply to comment #10)
> I had to replace 'platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#'
> with 'http://www.eclipse.org/emf/2002/Ecore#' in all my .ecore files to work
> around the NPE.

If you want to refer to something from ecore which is not an EDataType and not EObject itself, you have to use platform:/resource or platform:/plugin in the ecore files. Otherwise you'll end up with inconsistencies.

I'll update the docs to make this more clear.

Comment 13 Sebastian Zarnekow 2011-11-17 08:25:58 EST

Updated docs as well as quickfixes for inconsistent imported packages are available with 2.1.1

Marked as resolved.

Comment 14 Matthias Austruy 2016-05-18 10:08:34 EDT

Sorry to re-up that bug which seems burried for years.

But I'm facing that problem, exactly. I'm using Mars.2 Release (4.5.2).

Comment 15 Eclipse Webmaster 2017-10-31 11:27:12 EDT

Requested via bug 522520.

-M.