'Ecore Model Editor' fails with errors when opening Ecore file whose structural features reference external eType by URI

[ideas-into-software]

This problem was discovered when serializing dynamic EMF model, whose structural features reference external eType by URI, then opening such serialized Ecore with 'Ecore Model Editor', i.e.:

<eClassifiers xsi:type="ecore:EClass" name="ServiceReferenceDTO">
    (...)
  <eStructuralFeatures xsi:type="ecore:EAttribute" name="usingBundles" eType="ecore:EDataType http://gecko.io/converter/1.0#//ELongArray"/>
</eClassifiers>

Ecore referred to is the https://github.com/geckoprojects-org/org.gecko.emf.utils/blob/snapshot/org.gecko.emf.converter.model/model/converter.ecore, which has nsURI defined as http://gecko.io/converter/1.0.

So far, in projects where external Ecore files where referred to, relative path notation was used, instead of URI - e.g. in recently delivered OSGi stack implementation of "OGC API Features, Part 1: Core" standard ( https://github.com/de-jena/ogc-features/ ), that is how de.jena.ogc_features.model.core refers to LinkType type defined in de.jena.ogc_features.model.atom:

<eClassifiers xsi:type="ecore:EClass" name="ConformanceDeclaration">
    (...)
  <eStructuralFeatures xsi:type="ecore:EReference" name="links" lowerBound="1" upperBound="-1"
        eType="ecore:EClass ../../de.jena.ogc_features.model.atom/model/atom.ecore#//LinkType"
        containment="true" resolveProxies="false"/>
</eClassifiers>

Even though http://gecko.io/ domain name is used in several other Gecko projects as nsURI ( e.g. http://gecko.io/utils/1.0 in https://github.com/geckoprojects-org/org.gecko.emf.utils/blob/snapshot/org.gecko.emf.util.model/model/utilities.ecore ), and nslookup shows it has its DNS configured, there is no server listening at that address. This results in ConnectException: Connection timed out error when opening such Ecore file in 'Ecore Model Editor'; see attached screenshot (Screenshot from 2024-05-24 04-34-24.png).

Temporarily changing nsURI in such Ecore ( https://github.com/geckoprojects-org/org.gecko.emf.utils/blob/snapshot/org.gecko.emf.converter.model/model/converter.ecore ) to http://gecko.org/converter/1.0 - i.e. using the other, working Gecko domain name - results in another set of errors when opening Ecore file which refers to it, i.e.:

Problems encountered in file "http://gecko.org/converter/1.0"
  
  PackageNotFoundException: Package with uri 'null' not found. (http://gecko.org/converter/1.0, 1, 7)
  
  ClassNotFoundException: Class 'html' is not found or is abstract. (http://gecko.org/converter/1.0, 1, 7)
  
  XMIException: org.xml.sax.SAXParseExceptionpublicId: http://gecko.org/converter/1.0; systemId: http://gecko.org/converter/1.0; lineNumber: 6; columnNumber: 3; The element type "hr" must be terminated by the matching end-tag "</hr>". (http://gecko.org/converter/1.0, 6, 3)
  
    SAXParseException: The element type "hr" must be terminated by the matching end-tag "</hr>".

.. i.e. the result of attempting to parse "404" page displayed at http://gecko.org/converter/1.0; see attached screenshot (Screenshot from 2024-05-24 04-35-35.png).

None of the resource "save options" I checked (e.g. OPTION_SCHEMA_LOCATION_IMPLEMENTATION, etc.) helped to fix this problem.

Question is then whether this problem can / should be remedied or ignored ? If ignored, unfortunately editing such Ecore files using 'Ecore Model Editor' is not possible anymore then.

See attached Ecore files if you wish to reproduce above mentioned errors.

---

sample-ecores.zip

[ideas-into-software]

@juergen-albert Please let me know how you'd like to proceed with this, so I can incorporate necessary fix in #59, which already contains fixes for two other issues encountered.

[juergen-albert]

That is not really an issue of the created ecore, but an issue of the IDE. When the IDE e.g. loads the testConvertOSGiFrameworkDTO_gecko-org.ecore it tries to resolve the DataTypes the URIs point to. http://www.eclipse.org/emf/2002/Ecore is in the registry of the IDE, so it can resolve them. when it tires lot parse the Attribute using Bundles, it encounters the Package URI http://gecko.org/converter/1.0 which it can't find in its registry. As a reasult it tries to load it from the given URI, which produces an HTML it rightfully complains about.

In the IDE only few packages are known via their package URIs. They are usually refered to by some plattform: URIs, tha eclipse translates into Bundles or projects it looks into.
You can install https://projects.eclipse.org/projects/modeling.epsilon in your IDE. With this you can right click an ecore (or the package in the ecore itself) and will find something like a Load into registry entry. After loading the ecore or your package, it should be able to open it correctly.

[ideas-into-software]

@juergen-albert Thank you for the tip regarding "Eclipse Epsilon". To summarize:

• I used https://download.eclipse.org/epsilon/updates/ update site to install "Epsilon EMF Integration" components ( "Epsilon Development Tools for EMF 2.5.0.202404150823" + "Epsilon EMF Integration 2.5.0.202404150823" ), then
• registered http://gecko.io/converter/1.0 via "Register EPackages" context menu, and
• was able to see that package in the new "EPackage Registry" Eclipse view.

This took care of opening above mentioned Ecore file with 'Ecore Model Editor' - i.e. no more issues, as references to http://gecko.io/converter/1.0 model can be resolved properly.

Loading such Ecore file programmatically also does not cause errors - i.e. its structural features which reference http://gecko.io/converter/1.0 are also resolved properly.

However, errors still appear when attempting to generate Java code off such Ecore - both via Eclipse and Gradle ( i.e. run from command line ).

Attached please find:

• genmodel log, generated when run via Eclipse - same errors can seen when run via Gradle, of course;

• sample project, which contains such Ecore file - you can use it to reproduce this issue, just drop it in org.gecko.emf.utils workspace;

How should such cases be handled ? In part, that was the intent of my earlier question - as I explained, I wanted to resolve such cases programmatically where needed / produce Ecore which can be resolved properly - but none of the resource “save options” I checked (e.g. OPTION_SCHEMA_LOCATION_IMPLEMENTATION, etc.) helped to fix this problem.

---

OSGiFrameworkDTO-genmodel.log
org.gecko.emf.converter.model.poc_1.zip

[juergen-albert]

This might be an issue of the Codegenerator. But to make sure, can you please check something for me, before I dig into the code:

When you right click on the genmodel and select reload, you will finally end up with a wizard page like this:

Can you make a screenshot of this as well?

[ideas-into-software]

@juergen-albert No problem - here are screenshots, as well as screencast - screencast is much better, as it captures exactly when this problem happens, i.e. after clicking Next, having selected Reload for that genmodel.

Screencast.from.2024-06-14.00-44-25.mp4

Screenshots from 2024-06-14 00-43-.zip

[ideas-into-software]

@juergen-albert Please let me know if you have all required info now, so I'll close this issue, as it's not org.gecko.emf.utils but code generator related - the other two fixes I applied are in PR #59 which will be merged once #61 ( or #60 ) is merged.

[ideas-into-software]

@juergen-albert Closing as this issue is not org.gecko.emf.utils but code generator related and I have not heard back from you having provided all info you requested; assuming you have everything needed to debug it.