Re: [papyrus-rt-dev] [Neon] in Progress

[Christian Damus <give.a.damus@xxxxxxxxx>]

Hi, Peter,

More f’up, below, with some excisions.

cW

On 8 April, 2016 at 07:23:58, Peter Cigéhn (peter.cigehn@xxxxxxxxx) wrote:

Hi,

I have tried a little bit more, and I seem to bump into some issues with Mylyn and the pre-configured queries which don't seem to work. Have anyone else gotten the queries in Bugzilla and Gerrit up and running? Without having looked into the details it feels like not all connectors are installed, e.g. the Bugzilla, Gerrit and Hudson connectors seem to be missing.

Ah, yes.  Some tools that I never use but still try to set up for others. 😉  I always start by closing these Mylyn views, so I don’t notice problems.  I’ll look into it.

Some more comments/replies inline below.

/Peter Cigéhn

On 8 April 2016 at 12:59, Christian Damus <give.a.damus@xxxxxxxxx> wrote:

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.

This is now fixed in the latest patch.

———— 8< ———— 

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.

​As I see it, the profile is the core of core! :)

We have a separate feature for only the profile, so it could makes sense to have the profile in a separate subproject as well. Also I can foresee that anyone that wants to contribute only changes to the profile (and there I include myself, since I have already contributed the latest update of the profile adding some additional constraints to it).​

   

​But on the other hand, if you make updates to the profile, then you need to regenerate the validation plugin as well. And that one is part of Core... So maybe it is best to keep them in the same subproject/working set anyway. 

Could we at least make it more clear to name the subproject "Core/Profile" or "Core+Profile" or something like that to make sure it is clear that the profile is included?​

Too late!  😝  The latest patch breaks this out into its own Profile sub-project.

———— 8< ———— 

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.

​Yes, I had also hoped that the .gitattributes would solve this. But knowing that EGit (which is what I personally only use), does not yet support it. Instead I have the the core.autocrlf set to true. Is that something that should/could be set by Oomph? How do Oomph handle platform specific settings, i.e. some settings should only be made on Windows?

I haven’t seen any Oomph project attempt to configure the user’s environment for other tools than Eclipse.  Its purpose is for provisioning Eclipse platform, and I wouldn’t want the setup to try to poke around in the user’s system-wide git settings.  And maybe the Oomph team wouldn’t accept it into the catalogue if it did.

It sounds like EGit will be supporting at least this much of the .gitattributes capability soon(-ish)?  We can hope so.

———— 8< ————