Fornax-Platform
Forum

 « Return to Thread: [Sculptor] extension parser clash

Re: [Sculptor] extension parser clash

by Patrik Nordwall :: Rate this Message:

Reply to Author | View in Thread

Very good that you found this. I don't know if it is possible to solve this in any other way than changing the associated extension for sculptor dsl plugin.

Way back in time Andreas and I actually talked about using some other more fancy names for the DSLs, and their file extensions. Our source of inspiration was: http://www.plastermaster.com/sculpturehouse/index.htm :-)
and the suggestion was
chisel for the business tier DSL, i.e. model.design > model.chisel
rasp for the GUI DSL, i.e. model.guidesign > model.rasp

What do you think?

/Patrik

polly.c.chang wrote:
Oh, will the pain never end with this file resolving problem!  I had everything working great.  Design files were getting resolved from the classpath and there were no errors.  I was about to test the condition that you asked me to check in the other thread.  Then I discovered that the evil red "cannot resolve" markers came back.  I turned on my breakpoints again and waited for them to be hit.  Nothing.  Eclipse flew past everything.

All my breakpoints in org.openarchitectureware.xtext.registry.CachingModelLoad, org.openarchitectureware.xtext.registry.ClasspathUriUtil, TMFJdtClasspathUriResolver (the file I got from TMF), and oAW's org.openarchitectureware.xtext.registry.JdtClasspathUriResolver were being ignored.  How could this be?  So then I found org.openarchitectureware.xtext.editor.marker.MarkerManager.  Apparently this is where the red markers are coming from.

I debugged into this class and found that inside internalParseAndAnalyze(), on line 180, it tries to get the resource factory:

                Object factory = Resource.Factory.Registry.INSTANCE.getFactory(uri);

Apparently it was trying to find the resource factory for the file extension "design".  Well, it returns org.eclipse.datatools.connectivity.oda.design.util.DesignResourceFactoryImpl instead of the sculptordslResourceFactory.  Then I remembered that I saw this error in the .log file before:

Both 'com.foo.dsl' and 'org.eclipse.datatools.connectivity.oda.design' register an extension parser for 'design'

So apparently this is the problem.  The following line of code tests to see if the factory is an instance of IXtextResourceFactory.  It's not, so the oAW code does not bother trying to resolve anything.  That's why the error markers are there.  I verified that this is the problem by going into the datatools plugin and hacking its plugin.xml to change the extension to "design2" like this:

  <extension point="org.eclipse.emf.ecore.extension_parser">
    <parser
       type="design2"
       class="org.eclipse.datatools.connectivity.oda.design.util.DesignResourceFactoryImpl" />
  </extension>

Then voila!  It worked!  It appears that there's a race condition where sometimes Sculptor wins and sometimes this other plugin wins.  Since this plugin comes default in Eclipse 3.4.2 JEE edition, I cannot disable it, and this is the platform that our company is standardizing on.  So do you have any idea how to get rid of this conflict short of renaming the file extension?  

Thanks!
--Polly

 « Return to Thread: [Sculptor] extension parser clash