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 Peter,

If we pin the builds to Papyrus Neon.2, the users should still be able to use a later version of Papyrus. Minimum version should be Neon.2, but the users would be allowed to install a later version. However, the tests won't correspond to the version they will install, but to the integration of Papyrus-RT 0.9/1.0 & Papyrus Neon.2. If the behavior of Papyrus has been modified between the official release of Neon.2 and the version they install, they may encounter issues that tests won't detect. So it is usually better to build and install the same versions.

If there are some bug fixes required that can be only produce on Core Papyrus after it has been released as Neon.2 (i.e. no workarounds are possible), then we have to rely on a post-Neon.2 release, being an intermediate release or Neon.3 release.

Finally, I will ask the Papyrus team if they can produce the tag for release Neon.2. It is usually part of the release process, so something may have been missed. 

Regards,
Rémi



2017-01-10 10:01 GMT+01:00 Peter Cigéhn <peter.cigehn@xxxxxxxxx>:
Hi,

I am not fully sure that I understand the implications of "pinning" the builds of Papyrus-RT to the Neon.2 release. As Christian indicates, what about picking up the bug fixes that has been made after the Neon.2 release? When checking the Papyrus Git repo there are at least 2 commits after the Neon.2 release (since the Neon.2 release has not been tagged in the repo it is a bit hard to know exactly which commit was used for building Neon.2), one made by Christian related to the creation of ConnectorEnds and one by Asma related to a fix in the RSA model import.

If we pin to Neon.2, will that mean that we will not pick up the needed bug fixes made after Neon.2? And will that really be sufficient for a 0.9/1.0 release of Papyrus-RT?

Or is this a more "internal" issue? Can a "consumer" of Papyrus-RT still install it on top of the latest nightly of Papyrus, to get the latest fixes anyway, e.g. any further fixes in the RSA model importer for example?

/Peter Cigéhn

On 9 January 2017 at 14:23, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Nope, nothing else of a blocking severity comes to mind. Will definitely not want to bring this particular work-around into Oxygen, though, so I still need to raise the necessary Papyrus bugs.

cW

On Jan 9, 2017, 07:46 -0500, Remi Schnekenburger <rschnekenburger@eclipsesource.com>, wrote:
Hi,

Yes, that would remove the urgency. 
Do you feel the need for or do you already know some other bug fixes where you would need Papyrus new release? If not, that would be great to rely still on the Neon.2 release. 

Regards,
Rémi

 

2017-01-09 12:59 GMT+01:00 Christian Damus <give.a.damus@xxxxxxxxx>:
Hi, Rémi,

As it happens, I found a work-around over the week-end for the Model Explorer (and GMF diagrams) making it so difficult to override the Delete command handler, so that is no longer blocking me.  I’m not sure that it changes the situation, but perhaps it puts off the urgency?

Cheers,

Christian

On Jan 9, 2017, 03:15 -0500, Remi Schnekenburger <rschnekenburger@eclipsesource.com>, wrote:
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@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@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



_______________________________________________
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