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