Hi, Peter,
Thanks for running this setup model through its paces. Much appreciated.
Find some replies in-line, below.
cW
On 8 April, 2016 at 05:54:51, Peter Cigéhn (peter.cigehn@xxxxxxxxx) wrote: 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.
I hadn’t noticed that one of the Core bundles requires this CPP library, which I suppose is actually due to be renamed and moved to another repository imminently. I can fix that. But the other question of generating code and classpath folders is one that I don’t think should be addressed by the setup model. As I discussed with Ernesto, this really needs to be implemented as a project builder so that it may be kept continually up-to-date.
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.
Well, I thought to myself what could be more “core” to the Papyrus-RT architecture than the profile? So that’s the sub-project in which I put it. This could just be my outsider perspective on the project: do people generally see this as really such a distinct component? If so, we can put it in its own sub-project.
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. :)
Yes, that’s because the run-time is a kind of component that I’m quite unfamiliar with. I don't know what bits in the repository actually need to be imported as what kinds of workspace projects. I’d prefer to leave it to the run-time experts to add the run-time to the setup model.
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.
As I don’t understand (yet) the ways in which the XtUMLRT plug-ins fit into the architecture, I mostly just followed the directory structure in git and common bundle-name prefixes to group things. I welcome contributions from those that are familiar with these bundles to improve their organization in the setup.
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?
My follow-up Gerrit patch 68572 for common project configurations actually ensures (using the Oomph project configuration tooling) that all source projects are intrinsically set to UTF-8 encoding. I hesitate to put that as the workspace default also in the setup because the setup can be mixed with others for multi-project development in a workspace, and other projects may have different needs. And specifying this setting in the source projects ensures that non-Oomph users get the setting, too. Does that sound okay?
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.
We already have a .gitattributes file in the repository that enforces sane line-ending behaviour, so I think we might just leave that to git (this is traditionally a source-control system concern, I think)? Again, also support the non-Oomph people. But, the rest of the team may feel differently. I think this one should be a consensus decision.
I will try around a bit more to see if I find some more things to bring up.
Great!
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|