Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] First Papyrus-RT Oxygen Product Build
Hi Rémi,

Yes, that is my conclusion also. As I wrote on Mattermost, those regression seem highly likely related to some issues with the expansion model for adding the internal transitions compartment to states.

/Peter Cigéhn

On 10 May 2017 at 08:52, Remi Schnekenburger <rschnekenburger@xxxxxxxxxxxxxxxxx> wrote:
Hi Ernesto,

The regressions in tooling/migration seems in sync with the current regressions in tooling master job after Oxygen migration. So please ignore them currently, these are the regressions I should work on soon. 

Cheers,
Rémi

2017-05-09 16:06 GMT+02:00 Ernesto Posse <eposse@xxxxxxxxxxxxx>:
Right. So we could either merge my Gerrits (which add Guava 18 explicitly) and, if Xtext does move its upper boundary to 21, we update it later, or do we wait until Xtext has decided what to do?

BTW, I can't really merge 96604 yet because Gerrit-Tooling and Gerrit-Migration are unstable with test failing. Any idea why is that?

--
Ernesto


On Tue, May 9, 2017 at 8:13 AM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Ernesto,

That quotation looks to me like the Xtext plan is to test for API compatibility and increase their dependency bounds to include version 21.  But, at any rate, the question of aligning every project on version 21 is still up in the air, going back to the Architecture Council for review, so we may still be dealing with deployment of multiple versions.

At any rate, I have no objection to doing what is necessary for us to continue linking correctly to Papyrus and to Xtext.  AFAIK, our usage of Guava is only in the most stable of their APIs, but it seems that even something like their Futures is seeing breaking changes these days, so who knows?  I think we should at least make an effort not to expose Guava types in our APIs to ensure that we don’t add to the OSGi wiring problems.

Cheers,

Christian

On May 8, 2017, 15:35 -0400, Ernesto Posse <eposse@xxxxxxxxxxxxx>, wrote:
I just got a response from the Xtext people about 2.12, in particular if they are going to move the dependency to Guava 21 and the response was:

> we are still discussing on this.
> likely we stay as we are and inc the max version to 21

That means that we might need to include a dependency to an older version of Guava (i.e. 18), otherwise the Codegen bundles won't be resolved. 

I've prepared a couple of gerrits to add Guava 18 explicitly: the TPs and MANIFESTs (96604) and the Oomph setup (96605). Are there any objections to merging them?

--
Ernesto Posse
Zeligsoft




On Mon, May 8, 2017 at 11:32 AM Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
Since projects are moving to Guava 21 and apparently we need Guava 18 to deal with Bug 516200, would there be any objections if I make the Guava dependency for codegen to be [18.0.0,22.0.0)?

--
Ernesto Posse
Zeligsoft


On Mon, May 8, 2017 at 11:28 AM Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
As far as I'm concerned we don't need Xtext 2.12. Remi updated the MANIFEST files to use

 org.eclipse.xtend.lib;bundle-version="[2.12.0,3.0.0)",
 org.eclipse.xtext.xbase.lib;bundle-version="[2.12.0,3.0.0)"

(although I thing he missed some).

I'm not sure why. I suspect it was because Xtext 2.12 is supposed to be released with Oxygen.

But it looks like Xtext 2.12 is actually causing some trouble. See Bug 516200. 

--
Ernesto Posse
Zeligsoft




On Mon, May 8, 2017 at 9:08 AM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Thanks, Peter.

I’ve updated the Gerrit.

Cheers,

Christian

On May 8, 2017, 08:05 -0400, Peter Cigéhn <peter.cigehn@xxxxxxxxx>, wrote:
Hi,

Regarding Xtext 2.12 it seem that it will be included in Oxygen M7:

https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14418.html

So I guess until then we need to add the Xtext p2 repo ourselves to the Tester Setup. Found the following p2 repo based on the changes in the referenced Gerrit change in the message linked above.

http://download.eclipse.org/modeling/tmf/xtext/updates/milestones/head/S201704271113

I made an update to my local version of the Tester Setup model file and was able to install Papyrus-RT Oxygen with no additional issues.

/Peter Cigéhn



On 8 May 2017 at 12:45, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
Hi,

I tried the Tester Setup model in Gerrit review, and bumped into an issue with a dependency that could not be satisfied. It looks like the bundle org.eclipse.papyrusrt.codegen has bumped its requirement on org.eclipse.xtext.xbase.lib to version 2.12. But from what I can see (when checking with the Oomph Repository Explorer), there is no such version available in any of the p2 repos that the Tester Setup model lists. Especially it is not (yet?) in the Oxygen release repo. And when checking the latest Papyrus-RT Neon nightly build, we are still using 2.10 of org.eclipse.xtext.xbase.lib (which is available in both the Neon as well as the Oxygen release repos).

Is it a strong requirement that we must use 2.12 for the Oxygen build of Papyrus-RT? Or can we revert to only require 2.10 again? From what I can see, the bumping from 2.10 to 2.12 was made in commit c1fa6fc90abf2b30a4c3beee97d81b83c93cb0f8.

Or do we need to explicitly add an additional p2 repo for Xtext (since we cannot (yet?) rely on the Oxygen release repo only)? Which p2 repo is that?

/Peter Cigéhn

On 4 May 2017 at 22:03, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Team,

Thanks to a tremendous amount of hard work by Rémi “The Rock” Schnekenburger with a few contributions by others, we have an Oxygen-based Papyrus-RT product build:
This is still missing some components whose Papyrus dependencies were (at least recently) not yet ready:
  • RSA(-RTE) Migration
  • ELK Diagram Layout
The p2 update site repositories for nightly builds are now updated as follows:
  • Neon Nightlies — because we do not have Neon stream builds, the last successful product build (#604) from the Neon times is copied to the download server
  • Oxygen Nightlies — this is a composite that redirects, as for Neon previously, to the latest successful product build on Hudson
The Developer Setup model (Oomph) is updated to use the latest nightly build (now from Oxygen).  It previously was picking directly out of the Hudson component builds whilst the product build wasn’t ready.

The Tester Setup model is in Gerrit review with updates that I think should be appropriate for the new Oxygen landscape, but I don't know that creating a new Oxygen-based workbench with Oomph is working yet even in this context.  Help with reviewing this will be appreciated.

There are regression failures in the Tooling component that we need to look at, skipped tests that need to be reviewed and restored to active duty, and probably numerous other small regressions to knock down.

Cheers,

Christian

_______________________________________________
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
--
Ernesto Posse
Zeligsoft
--
Ernesto Posse
Zeligsoft
--
Ernesto Posse
Zeligsoft
_______________________________________________
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
--
Ernesto Posse
Zeligsoft

_______________________________________________
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




--
Remi Schnekenburger

Senior Software Architect / General Manager
EclipseSource Paris

Email: rschnekenburger@eclipsesource.com
Web: http://eclipsesource.com/paris 
Phone: +33 1 85 41 08 65
German Phone: +49 89 21 555 30 - 25
Hangouts: rschnekenburger@eclipsesource.com

EclipseSource France SAS
7 rue de la Croix Martre
91120 Palaiseau

General Manager: Remi Schnekenburger
Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France
Commercial Register 824 977 516  R.C.S. EVRY

_______________________________________________
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


Back to the top