Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Dependency on Core Papyrus

Hi,

I understand that point. So we would have to ensure that Papyrus will provide a new release until the official  Neon.3 one. 
Is there a way for a temporary workaround for this issue? And do you see a lot of similar issues, that should be fixed on Papyrus itself?

Cheers,
Rémi


2017-01-06 23:02 GMT+01:00 Christian Damus <give.a.damus@xxxxxxxxx>:
Hi, Rémi,

I agree in principle, but how long can we go without picking up new nightlies from Papyrus with bug fixes?  Depending on new APIs is one thing (which we may want to avoid, yes) but we also depend on bug fixes to make Papyrus-RT more stable and usable.  AFAIK, we are still expecting that the next Papyrus-RT release will have to be on a “tweener” release of Papyrus before the Neon.3 release.  So, we would still need to be able to produce test builds on Papyrus Neon.x nightlies to verify Papyrus-RT.

For example, I need to fix the Model Explorer to make its handler for the Eclipse global Delete command overridable so that we won’t have a confusion in the context menu between the Delete command and a separate “Exclude Element” command.  This fix has to be in Papyrus, because it’s the Model Explorer view that chose to bind its handler to the most specific context that Eclipse Platform has to offer.

Cheers,

Christian

On Jan 6, 2017, 12:22 -0500, Remi Schnekenburger <rschnekenburger@eclipsesource.com>, wrote:
Hi team,

Since we are targeting a Papyrus-RT release based on latest release from Papyrus, what about moving the build jobs to depend on the papyrus release Neon.2 rather than nightly ? i.e. papyrus.kind=papyrusreleases rather than papyrus.kind=papyrusnightly in the build job configurations. That would give use a more stable platform, and we would ensure that we already test against latest release version, and do not introduce dependencies towards nightly APIs. 

I proposed a gerrit [1] to update target platforms for Papyrus release folder, the TPs now target the release neon.2. All gerrit builds are green, but they depend on the nightly TPs, so that's not relevant...
At the same time, I updated the junit util feature dependency to be lazy, as there is no stable release we can rely on. That may be the cause of the failing job about quality. That was also proposed by Céline in a unmerged patch.
  

Regards,
Rémi

[1] 
--
Remi Schnekenburger

Senior Software Architect / General Manager
EclipseSource Paris

Email: rschnekenburger@eclipsesource.com
Web: http://eclipsesource.com/paris
Mobil: +49 89 21 555 30 - 25 
Phone: +49 89 21 555 30 - 25
Fax: +49 89 21 555 30 - 19

EclipseSource France SAS
7 rue de la Croix Martre
91873 Palaiseau

General Manager: Remi Schnekenburger
_______________________________________________
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




--
Remi Schnekenburger

Senior Software Architect / General Manager
EclipseSource Paris

Email: rschnekenburger@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Mobil: +49 89 21 555 30 - 25 
Phone: +49 89 21 555 30 - 25
Fax: +49 89 21 555 30 - 19

EclipseSource France SAS
7 rue de la Croix Martre
91873 Palaiseau

General Manager: Remi Schnekenburger

Back to the top