| multi-module maven build [message #1548070] |
Mon, 05 January 2015 20:37  |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
During the process of migrating away from the fornax maven plugin, I had some difficulties configuring the different paths in the workflow of one particular project.
Goal: it should be possible to either build the entire multi-module thing, or just build one individual dsl project.
My trial-and-error process led me to a solution that looks a bit strange:
var projectName = "com.my.dsl.project"
var grammarURI = "platform:/resource/${projectName}/src/main/java/com/my/dsl/MyDSL.xtext"
var file.extensions = "mydsl"
var src.dir="/src/main/java"
var src.gen.dir="/target/generated-sources/xtext"
var parentPath=".." // preferably override from pom.xml to a canonicalized path
var runtimeProject = "${parentPath}/${projectName}"
Workflow {
bean = StandaloneSetup {
resourceSet = org.eclipse.xtext.resource.XtextResourceSet:theResourceSet {}
scanClassPath = true
platformUri = "${parentPath}"
registerGeneratedEPackage = ...
registerGenModelFile = ...
}
... (DirectoryCleaner)...
component = Generator {
pathRtProject = runtimeProject
pathUiProject = "${runtimeProject}.ui"
projectNameRt = projectName
projectNameUi = "${projectName}.ui"
srcPath = "${src.dir}"
srcGenPath = "${src.gen.dir}"
mergeManifest = false
language = {
forcedResourceSet = theResourceSet
uri = grammarURI
fileExtensions = file.extensions
fragment = grammarAccess.GrammarAccessFragment {}
fragment = ecore.EMFGeneratorFragment {
javaModelDirectory = "/${projectName}${src.gen.dir}"
xmiModelDirectory = "${runtimeProject}${src.gen.dir}"
updateBuildProperties=false
}
...
While I could interactively run this workflow in the IDE (Run as...) , for maven builds I had to pass the parameter 'parentPath' with a value that requires a little hack in groovy:
def path=new File(project.basedir.canonicalPath+"/..").canonicalPath;
if (path.charAt(0) == '/')
pom.properties['parentPath'] = path
else
pom.properties['parentPath'] = "/"+path
println("parentPath="+pom.properties['parentPath'])
What's particularly strange here is the asymmetry between javaModelDirectory and xmiModelDirectory:
- javaModelDirectory must have the shape /projectName/relativeDirectory, because this path will be used in a platform:/resource URI
- xmiModelDirectory must be an absolute filesystem path
Interestingly, any other shape of path in javaModelDirectory let the generator fall over the paths for generated java files: the generator complained that these paths were "not mapped". Paths were internally expanded to correct absolute filesystem paths, so I have no idea, why these needed to be mapped further.
(Also, coming from the old (deprecated) EcoreGeneratorFragment it took me a while to figure out, how to configure the output paths at all - the old one seemed to rely more on srcGenPath of the enclosing Generator configuration.)
Finally, s.t. kept adding "model/" to bin.includes in build.properties although such directory is never used, leading to a build failure next time around. Yes, I can explicitly suppress this behavior, but why would the generator add a wrong path in the first place?
Bottom line: the above works, but it feels strange that only this particular skewed combination could be made to work. Am I missing s.t. obvious? Are multi-module builds uncommon for Xtext projects (I wouldn't think so)?
Otherwise I hope that the above might be helpful for others running into similar situations 
Stephan
|
|
|
| Re: multi-module maven build [message #1549065 is a reply to message #1548070] |
Tue, 06 January 2015 09:52  |
|
Hi Stephan,
we have an example Xtext project build using tycho.
Maybe it helps you to look into:
https://github.com/dhuebner/xtext-builddsl-tycho
I'm not sure xmiModelDirectory setting is necessary at all. If you generate to a source folder, your URI will be different at developing time (WS) and runtime (jar), missing src-gen part at runtime. The better way is to generate to the .../model/generated folder.
Regards,
Dennis.
+Dennis Huebner
Get professional support from the Xtext committers at www.typefox.io
|
|
|
| Re: multi-module maven build [message #1549115 is a reply to message #1549065] |
Tue, 06 January 2015 10:34 |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Thanks Dennis,
The first significant difference I see: in your project the maven parent has its child modules in sibling directories, not child directories. That certainly makes a huge difference. If that's the structure for which the tools have been designed and tested, perhaps the Xtext team may want to recommend this structure at a prominent place in the documentation (too late for me, though). This could well explain why configuring a project with child module = child directory feels like driven off-road.
Regarding colocation of model and source: yes, I recently learned that this is not a good idea, but still I'd like to adhere to the Maven convention that everything is either in src/main/something or in target/something. Additionally, my need to define xmiModelDirectory may have just been a consequence of the directory layout mentioned above.
Your definition of 'javaModelDirectory = "/${projectName}/src-gen"' confirms a result of my debugging: this path must be interpretable as a suffix to "platform:/resource". Sounds like s.t. worth documenting in EMFGeneratorFragment. This is particularly relevant, since xmiModelDirectory seems to apply different semantics (file path not interpreted via "platform:/resource").
It seems that after one fundamental design choice differing from your assumptions I will continue to challenge "unusual" situations
cheers,
Stephan
|
|
|
|
| Re: multi-module maven build [message #1549252 is a reply to message #1549129] |
Tue, 06 January 2015 12:13 |
|
Quote:The 'model' directory must be a toplevel directory in the project, right? So even src/main/model doesn't cut it..
The location for the generated emf files should not be a part of the java source folder. because there location will differ after packaging them in to a jar. So the URIs computed during the build time will not be the same as at runtime. Thats all.
Regarding the case where you would like to put your main pom in root folder, I don't think it's will cause any problems. It's only about how you calculate the runtimeProject Path in your module pom.xml
+Dennis Huebner
Get professional support from the Xtext committers at www.typefox.io
|
|
|
|
|
| Re: multi-module maven build [message #1549381 is a reply to message #1549362] |
Tue, 06 January 2015 13:45 |
Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Dennis Huebner wrote on Tue, 06 January 2015 14:31Stephan, it's difficult to say whats exactly goes wrong, when calculating path.
Is it possible to look into your project source code?
Dennis, thanks for the offer.
Unfortunately that project is not open-source.
OTOH, if I use the exact setup from my initial post, all seems well. I was only puzzled why a gazillion (I'm slightly exaggerating ) other configurations did not work. Debugging told me that the different path configurations are processed differently. Hence I'm suggesting to document the assumptions, because without such documentation everybody using a non-standard setup has to repeat my debugging party (which was much less fun than you expect from a party...).
From all my observations:
- Generator.srcGenPath will be appended to the project's path to yield a file system path
- EMFGeneratorFragment.javaModelDirectory must have the shape "/projectName/relativePath" because it will get a prefix "platform:/resource" prior to evaluation.
- EMFGeneratorFragment.xmiModelDirectory is directly interpreted as a file path, nothing prepended (not sure if it can be relative to some current directory, absolute path works fine).
Just saying "path" in all three locations is not sufficient for unsuspecting clients. Do you see my point?
best,
Stephan
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03311 seconds
] 
Search
Help
Register
Login
Home
