[Sculptor] extension parser clash

[polly.c.chang]

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

[Patrik Nordwall]

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

[PaloT]

Maybe I'm too old I like more something like Scultor Business Tier -
sbt extension. It will be also good idea to consider using all *.sbt
files in specific directory (and subdirectories) as model source
instead of including files to one main file. I don't know if oAW allow
this but it will be also nice feature.

Regards

Pavel

---------- Forwarded message ----------
From: Patrik Nordwall <patrik.nordwall@...>
Date: Thu, Apr 16, 2009 at 10:03 PM
Subject: Re: [Fornax-developer] [Sculptor] extension parser clash
To: fornax-developer@...



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
>

--
View this message in context:
http://www.nabble.com/-Sculptor--extension-parser-clash-tp23068724s17564p23085354.html
Sent from the Fornax-Platform mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Fornax-developer mailing list
Fornax-developer@...
https://lists.sourceforge.net/lists/listinfo/fornax-developer

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Fornax-developer mailing list
Fornax-developer@...
https://lists.sourceforge.net/lists/listinfo/fornax-developer

[polly.c.chang]

Hi Patrik,

I am happy to report that I resolved the problem by changing the extension to something unique.  I haven't seen any more error markers related to loading files from the classpath.  I hope that luck stays!  I'll go back to look at the other scenario that you wanted me to test.

Regarding the extension names, the fancy names like "chisel" and "rasp" are kinda cool, but they would probably be too cool at my work.  Something like what Pavel said ("Sculptor Business Tier") is a little ordinary but is serious and professional.  :)  Just my 2 cents.

Thanks,
Polly

Patrik Nordwall wrote:

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