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