Hi,
I have tested the setup-file a bit (fetching it from Gerrit). Here are some comments/questions/proposals:
1) I started by only importing the top-level Papyrus-RT project, and the added the sub-projects one-by-one. When I only had installed the Tooling, I could one compile error that org.eclipse.papyrus.cpp.library bundle could not be resolved for the org.eclipse.papyrusrt.umlrt.core.cpp bundle. When I later added the Codegen subproject, this compiler error disappeared (and a lot of new ones appeared related to the missing directories and generated code). I am not sure if this causes by some missing repo or requirement in the setup-file, or if it something else that causes this. I guess, it is good if you can choose to only bring in the Core subproject without compile errors.
2) I wonder if we should separate the Profile into its own subproject/working sets. I was a bit confused to find the Profile included in Core. If we do not choose to have an own subproject/working set, then at least consider to name the subrpoject/working set Core + Profile or something like that to make it clear where the profile is included.
3) Related to the same I was also a bit confused that the run-time was not mentioned or included in any of the subprojects. I have no idea if it the run-time parts are supposed to be included or not, I was just suprised that I could not find any traces of it! But maybe the run-time is only considered to be external C++ code, so the development of that is outside the scope of the "normal" development. :)
4) The current XtUMLRT maybe should be split into a separate part for the Textual stuff, and keep only the meta-model (the stuff that IncQuery relies on) in a separate subproject/workingset. Not sure about the name either. I would expect it to be named xtUML-RT, or something like that. But I have not been involved here to know. Maybe Erneste can give his view regarding the name and scope of this subproject and contents of the working set.
5) Finally I have a question related to one more issue the Ed Willink raised (apart from this about generated code) in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=479633 about UTF-8. I bumped into the same issue as Ed did, and I had to change the default encoding in my workspace to UTF-8 (since I am on Windows it is by default Cp1252) which caused some issues with the Xtend source files. My question if the solution is to set the default encoding to UTF-8 for the worksapce or if it should be set explicitly on those projects that rely on UTF-8. And if it shall be set on workspace level, shouldn't then that be in the Oomph setup to ensure everone have the right setting of this?
6) Slightly the same goes for the setting "New file text file line delimiter" which I read somewhere should be set explicitly to Unix (to avoid the line-ending issues that we have discussed before). Maybe that is also something that shall be set by the Oomph-setup file to ensure everyone have the correct settings.
I will try around a bit more to see if I find some more things to bring up.
/Peter Cigéhn