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-tp23068724s17564p23068724.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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fornax-developer
