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

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

Hi, Peter,

As the codegen component has two builds, one of which is a continuous integration and the other a true nightly, we might want a parameter in the setup that lets developers decide which they want.  For myself, as a tooling-focused person, I wouldn’t need to keep up so aggressively with the codegen.  I have found in working on Papyrus that almost every time I run Oomph, it downloads another nightly build, and they aren’t small.  It gets to be rather much after a while and requires a lot of bundle-pool garbage collection maintenance.

So, does that sound fair?  With a parameter in place, dev can opt for the continuous “repo” builds if they need to get going right away on Neon, and switch later if they want to.

cW

On 8 April, 2016 at 10:16:05, Peter Cigéhn (peter.cigehn@xxxxxxxxx) wrote:

Hi again,

I have now tried the latest patch set 8, and the Mylyn pre-configured queries works. We are getting there... :)

Next step I tried starting a runtime workbench, and started testing a bit. But then I bumped into the same kind of issue I did in my nightly build test installation. And we once again bump into this confusion about "nightly builds". I see that you have chosen the ${base.downloads.url}/papyrus-rt/builds/nightly/ as the repo for downloading "nightly" builds for the codegen/runtime parts, instead of ${base.downloads.url}/papyrus-rt/builds/repo/ (which is the one that I would have picked).

I really think that for consistency the repo-repo shall be used (since the build of that one is triggered directly by a push to master, in the same way as the "nightly" builds for the core/profile/tooling parts in the repo on Hudson).

Now we are in a situation also where the nightly repo for the codegen/runtime never have succeded building on Neon (see https://hudson.eclipse.org/papyrus-rt/job/Papyrus-RT-CodegenRTS-BuildFrom-gitroot-Triggered-nightly-PublishTo-nightly/), so we still have Mars contents in this repo, causing the runtime workbench to fail, even for such a basic case as creating a new model.

We really need to settle this about "nightly builds", i.e. whether they should be a time trigger built every 24 hours, or if a "nightly build" is built as soon (within 20 minutes) as new push has been made to the master branch. Personally I really do not see the need for having to wait 24 hours to get a "nighty build", at least not for developers who want to be working on the "bleeding edge".

But maybe I am wrong. But currently we have it very inconsistent where we pick up 20-minute builds for the core/profile/tooling and 24-hour builds for the codegen/runtime parts. I really think that we need to be consistent. And we should at least get one 24-hour build for the codegen/runtime parts to have succeeded so that we can have a consistent neon target definition in the runtime workbench.

/Peter Cigéhn

On 8 April 2016 at 15:11, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

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

_______________________________________________
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