EDataType could not be resolved about nmf HOT 15 CLOSED

The current version of Ecore2Code only supports at most one occurence of each parameter. Thus, if you need to resolve multiple files, you need to separate them by ; like -r platform:/plugin/org.eclipse.bpmn2/model/BPMN20.ecore=BPMN20.ecore;platform:/plugin/org.eclipse.bpmn2/model/BPMNDI.ecore=BPMNDI.ecore. As soon as a reference contains the #-symbol, NMF tries to parse it as a URI. If it is not an absolute URI, it is treated as relative to the current document's URI.

from nmf.

Hi Umut,

I have never come across yet an Ecore that used the URI http://www.eclipse.org/emf/2003/XMLType#//String to reference the string type, therefore, NMF is not aware of that, yet.

The problem is that NMF assumes a unique identifier for all data types. The identifier used for the String data type is http://www.eclipse.org/emf/2002/Ecore#//String, not http://www.eclipse.org/emf/2003/XMLType#//String. Therefore, you could do either of the following:

1. Replace http://www.eclipse.org/emf/2003/XMLType with http://www.eclipse.org/emf/2002/Ecore in your Ecore file
2. Provide the .ecore file for http://www.eclipse.org/emf/2003/XMLType. NMF currently does not perform any web requests on its own, it only uses URIs as identifiers. You can provide the model using the command-line parameter -r http://www.eclipse.org/emf/2003/XMLType=file.ecore

The latter approach would be much cleaner (of course) but requires an additional model. If you have that model, I would be glad if you shared it, such that I can add support for this namespace out of the box in NMF.

Best regards,

Georg

from nmf.

Thanks for the quick response Georg

I have changed from XMLType# to Ecore# but still the same error.
An error occurred reading the Ecore file. The error message was: The reference ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//String could not be resolved

from nmf.

Sorry, I was a bit too quick here: The correct type name in Ecore is EString, so the URI should be http://www.eclipse.org/emf/2002/Ecore#//EString.

However, I also spotted that you use feature map entries and string to string map entries. These are currently not supported.

from nmf.

I have to revoke my last statement, actually they should be supported. The fact that NMF renders just the type name is a bug.

from nmf.

Thanks, now i have succesful message that says

Operation took 257.0456ms
Code generated successfully!

My command is Ecore2Code -f -n NMFDemo -o Metamodel -m library.nmf "path-to-ecore", but when i generate the code, Metamodel folder does not show up.

Anyway my original ecore file is much more complex and i don't want to bother you often. I will try to do things you explain in your video. (i think it is your video, isn't it)
https://www.youtube.com/watch?v=NIMYuwTltVs

Thanks again Georg, i appreciate the help :)

Kind regards,
Umut

from nmf.

I just fixed the bug. A new version of the code generator should be available in a couple of minutes. Then, you will be able to generate code for the example. However, NMF only supports StringToString maps directly (because their structure is reflected in Ecore). If you really need feature maps, then you have to reimplement them in a class and reference the class in the code generator.

P.S.: Yes, that is my video :). If you need more help, just ask. If you think it is getting overwhelming, we can set up a project for that.

from nmf.

The fact that Visual Studio does not show the generated files may be because NMF does not modify the project. You have to show all files in Visual Studio and then, you can include them into the project.

from nmf.

I got the Metamodel folder, my mistake.

I will dig into it more but if i need help or my team decides to go with nmf (to convert our emf project to nmf) i will get in touch with you.

Again, thank you very much :)

from nmf.

Hello Georg again,

Can you help me about an error message about DocumentRoot?

The reference platform:/plugin/org.eclipse.bpmn2/model/BPMN20.ecore#//DocumentRoot could not be resolved

I've started to try generating my original file.

from nmf.

This seems like your metamodel references BPMN. As I said earlier, Ecore2Code does not try to resolve URIs other file URIs, so you have to provide the file through a command-line parameter: -r platform:/plugin/org.eclipse.bpmn2/model/BPMN20.ecore=BPMN20.ecore, provided that the BPMN metamodel is in the working directory.

from nmf.

Thanks,

so there are these

<eStructuralFeatures xsi:type="ecore:EReference" name="diagrams" ordered="false"
        upperBound="-1" eType="ecore:EClass BPMNDI.ecore#//BPMNDiagram" containment="true">
      <eAnnotations source="http:///org/eclipse/emf/ecore/util/ExtendedMetaData">
        <details key="kind" value="element"/>
        <details key="name" value="BPMNDiagram"/>
        <details key="namespace" value="http://www.omg.org/spec/BPMN/20100524/DI"/>
      </eAnnotations>
    </eStructuralFeatures>

lines in BPMN20.ecore. And now i have an error message says

The reference ecore:EClass BPMNDI.ecore#//BPMNDiagram could not be resolved

How should i add BPMNDI.ecore to command-line? I know multiple entries separated by ; but couldn't run the command

from nmf.

Could you please take a look at this image? Is it possible that something broken about multiple entries command?

from nmf.

The exception handling of NMF is probably not the best. Ecore2Code goes through all of the input and tries to load the specified metamodels. If a metamodel fails to load, Ecore2Code goes on as if the metamodel was omitted. This is why you see the error message that no package was found.

The other thing is that I fear that ; is a particularly bad choice for a separator when you use the command via PowerShell, because apparently, PowerShell treats the ; as a command separator and does not forward it to the command that shall be executed. This is at least my interpretation why Powershell seems to try to execute the URI as a command. The quick may be to put the ; in quotes, i.e. ";". This will tell PowerShell to pass the character to Ecore2Code.

Anyway, there is a new major version with support for .NET Standard 2.0 on its way and this will have to include a newer version of the library CommandLineParse that I use to parse the command line (even though these releases are not marked as stable). The newer versions of this library do support multiple occurences of the same parameter so this will hopefully be a bit more conveniant in the future.

from nmf.

Since there is no more response, I guess that the problem is solved now

from nmf.