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

[Peter Cigéhn <peter.cigehn@xxxxxxxxx>]

Hi,

Thanks for the explanation regarding the Papyrus setup. Just for my own understanding: If we are able to add the needed test plugins to the PDE Target for Papyrus-RT, shouldn't it be possible to do the same also for Papyrus, i.e. to include them in a targlet instead of importing the source projects into the workspace? From what I can see, there seem to be some issues with "Problem with release spec: /org.eclipse.papyrus.releng.dev.release/release.xml (Resource '/org.eclipse.papyrus.releng.dev.release' does not exist.)" for all the projects (even the two ones that you mentioned only were supposed to be imported originally), so there seem to be some "circular" dependency as welll, where each of the projects also depend on releng-project.

Anyway, that was more related to the Papyrus setup and maybe something to consider at the next update of the setup file for Papyrus. It would be nice also for Papyrus contributors to get a nice setup without any confusing compile errors when setting up a development environment for Papyrus. I myself was rather confused when I initially tried this for Papyrus (I thought that I had done something wrong on my side).

/Peter Cigéhn

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

Hi, Peter,

On 8 April, 2016 at 08:47:02, Peter Cigéhn (peter.cigehn@xxxxxxxxx) wrote:

Hi Christian,

I tested the updated the patch set and now the unresolved reference is fixed. Nice...

😁

Regarding the Mylyn issues, I tried just for the sake of it, to import the Papyrus root project also. And now the Mylyn queries seem to be "kick in", and start refreshing. So the Papyrus root project do seem to install the needed connectors.

Okay, thanks for confirming that the issue isn’t in the setup-configuration of the queries, but in the tooling installed.  I’ll fix that.

Even though this is more related to the Papyrus setup file, I was just wondering what the purpose of importing a few projects already by the root Papyrus project itself is? They don't seem to belong to any working set either, so they all end up "Other Projects" workingset.. And they don't compile, so you get a bunch of compilation errors, mainly related to unresolved refernces. Is that really the intention with only importing the root Papyrus project? When you are at it, maybe you could take a look at this scenario for the Papyrus setup file as well?

Initially, these projects that were imported at the root were only the org.eclipse.papyrus.junit.utils and org.eclipse.papyrus.junit.framework.  Since then, other plug-ins were added that match the same import specification.  And there are dependencies added over time that maybe weren’t accounted for in the setup.  It’s a lot to keep track of, and hard to notice when you just keep rolling along in the same workspace that you’ve always been using!

The idea with importing these by default was to ensure that, no matter what the user is doing, even if just adding new plug-ins that didn’t exist yet in Papyrus, they would have what’s necessary to add JUnit tests for their work.

In the case of Papyrus-RT, because we use the same core test framework as Papyrus, it seemed better to include these test plug-ins by default in the PDE Target.  So, no matter what you import from Papyrus-RT (even if just the top project), you will have these Papyrus test bundles in your PDE target ready to support your test development.

/Peter Cigéhn

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

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< ———— 

_______________________________________________
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

_______________________________________________ 
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 

_______________________________________________
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