Community
Participate
Working Groups
Build Identifier: 1.0 and 2.0 Hi, i currently try to setup the build for our xtext projects with maven. I followed the sample from Karsten blog: http://kthoms.wordpress.com/2010/08/18/building-xtext-projects-with-maven-tycho After playing around with the downloadable sample i figured out that the maven build stops working when renaming the project folders. The reason for that seems to me the fact that xtext uses the .project file in his sample to "guess" the project name. From my point of view this doesn't make much sense because: - i never submit the .project file into my versioning tool, due to this executing the build on our hudson will fail - the project name is available in the mwe2 workflow file, this one should used to generate the genmodel file Sry for not providing an fix i wasn't able to find the source which reads the project name from the .project file. Best Regards Andreas Reproducible: Always Steps to Reproduce: 1.Download and extract the sample from http://dl.dropbox.com/u/662339/Blogs/XtextTychoExample.zip 2. rename the projects from org.xtext.example.mydsl* to e.g. net.xtext.example.mydsl*, change all references of the name (e.g. in mwe2 file) 3. run the maven build with mvn clean install
We use EMF's platform:/resource URI scheme which at runtime also relies on the information from .project files. So we do use that at runtime in order to be able to get the same behavior. Why does your build job fail if you check in the .project file?
(In reply to comment #1) > We use EMF's platform:/resource URI scheme which at runtime also relies on the > information from .project files. So we do use that at runtime in order to be > able to get the same behavior. > > Why does your build job fail if you check in the .project file? Its the other way around. The build only succeeds if the .project file is submitted. From my point of view submitting this file isn't a good practice. Its getting modified depending on the workspace configuration of the user (e.g builder for checkstyle or other stuff), so changes are always accidentally submitted and the file gets messed up. I just have seen that it (could be) quiet easy to inject the project path configured in the mwe2 file into the ECoreFragmentGenerator. Isn't that a possible option?
The EcoreGeneratorFragment relies on what's in EcorePlugin.getPlatformResourceMap(). To add an entry you can simple call some java class wihch does : EcorePlugin.getPlatformResourceMap().put(projectName, URI.createFileURI(pathToProject)); from within your workflow.
