URIs generated into parser need to use "/plugin" URI instead of currently used "/resource" (#88)

[StephanErb]

In the generated parser URIs of, for example, SequenceElements are generated that are at runtime used to lookup the SequenceElement and assign it to parsed tokens. As during build time the syntax mapping is located in the workspace, the URIs of these elements are of the form:

"platform:/resource/com.sap.furcas.tcs.editor/mappings/TCS.tcs#//@templates.55/@templateSequence/@elements.0"

However, as the parser is used during runtime, the mapping won't be available in the workspace. Therefore, actually the following should be generated:

"platform:/plugin/com.sap.furcas.tcs.editor/mappings/TCS.tcs#//@templates.55/@templateSequence/@elements.0"

[StephanErb]

Stephan Erb (stephan@dev.static-void.de) wrote on 2010-12-19 13:37:04

Hi Thomas,

the code you are referring to is not yet in version control or is it? I am not sure how I can reproduce / test the mentioned issue.
The issue does not seem to be on the generator but only on the usage side. You could try the following to establish a mapping from 'resource' to 'plugin':
    resourceSet.getURIConverter().getURIMap().putAll(EcorePlugin.computePlatformURIMap());

Side node: Any objections if I pull the resource assignment of the concrete syntax out of the SyntaxParser? It seems like a separate concern to me and can as well be performed by the caller himself.

Best,
Stephan

[StephanErb]

Thomas Goldschmidt (mail@thomas-goldschmidt.de) wrote on 2010-12-21 17:14:22

 
> the code you are referring to is not yet in version control or is it?

No, not yet, it will be soon.

> I am not
> sure how I can reproduce / test the mentioned issue.
> The issue does not seem to be on the generator but only on the usage side. You
> could try the following to establish a mapping from 'resource' to 'plugin':
>        
> resourceSet.getURIConverter().getURIMap().putAll(EcorePlugin.computePlatformURIMap());
> 

I think this is not the correct solution, as during the parser runtime it seems more natural that the parser uses /plugin/ URIs. Instead of mapping the metamodel from /plugin/ to /resource/ I would like to generate /plugin/ directly in the parser. Thus, what I would need is a mapping the other way round when it comes to generating the parser. Maybe when can directly patch this where _beforeSeqEl() calls are generated?

> Side node: Any objections if I pull the resource assignment of the concrete
> syntax out of the SyntaxParser? It seems like a separate concern to me and can
> as well be performed by the caller himself.

SOunds ok for me.

Cheers,
Thomas

[StephanErb]

Stephan Erb (stephan@dev.static-void.de) wrote on 2010-12-21 17:26:09

Ah, I wasn't aware of the direct use of MOF-IDs/URIs within the generated parsers. 

Maybe it is enough to call the method below.  I will test that out once your code has landed.

Best Regards,
Stephan

  /**
   * Computes a map from platform:/resource/<plugin-location>/ {@link URI} to 
   * platform:/plugin/<plugin-id>/ URI
   * for each URI in the collection of the form platform:/plugin/<plugin-id>/....
   * This allows each plugin to be {@link org.eclipse.emf.ecore.resource.URIConverter#getURIMap() treated} 
   * as if it were a project in the workspace.
   * If the workspace already contains a project for the plugin location, no mapping is produced.
   * @param uris a collections of {@link URI}s.
   * @return a map from platform resource URI to platform plugin URI.
   */
  public static Map computePlatformResourceToPlatformPluginMap(Collection uris)

[StephanErb]

Stephan Erb (stephan@dev.static-void.de) wrote on 2011-01-06 12:58:23

Hi Thomas,

what is the status on this one? I have seen that you have made various commits. Is it already possible to somehow open a FURCAS model editor? If yes, what do I have to do?

Thanks,
Stephan

[StephanErb]

Thomas Goldschmidt (mail@thomas-goldschmidt.de) wrote on 2011-01-10 11:16:36

I implemented a workaround for this in ObservationDirectivesHelper::getId that
replaces "platform:/resource/" with "platform:/resource/". (Push is soon to
come). This works for now but I think we need to dicuss this further.

To be able to reproduce this you can just import the bibtex.dsl projec into a
runtime workspace and make changes in the .tcs file. The following build will
generate the URIs into the parser.

To open an Editor and test the parsing behaviour you can just use the provided test project "bibtex.test" with the contained model/LiteratureDb.bib model file. Just choose the Bibtex Editor from the available editors in "open with".

(In reply to comment #4)
> Hi Thomas,
> 
> what is the status on this one? I have seen that you have made various commits.
> Is it already possible to somehow open a FURCAS model editor? If yes, what do I
> have to do?
> 
> Thanks,
> Stephan
> 

[StephanErb]

Axel Uhl (furcas@homemp3.dyndns.org) wrote on 2011-04-11 11:14:57

The workaround doesn't address the TCS.tcs special case where the root cause for unresolvable URIs is a different one. The textual TCS.tcs mapping definition leads to the construction of a transient mapping model during the bootstrap. The mapping model is not stored in a persistent resource. Therefore, there aren't any stable URIs for the mapping elements which in turn leads to unresolvable URIs generated into TCSParser.java.

As we start depending on the URIs being resolvable when the parser runs (e.g., for obtaining the property inits for OCL update handling), this becomes an issue that needs to be fixed.

What is the reason for not storing the mapping model derived from TCS.tcs persistently?