And for the Model Import, most of the papyrus rt bugs are in fact papyrus bugs, to be fixed in the papyrus model importer.
I see another bug dealing with enhancing table layout that Nicolas fixed in Papyrus and Papyrus RT need this fix to have
an enhanced layout for tables: https://git.eclipse.org/r/#/c/88179/
Asma
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx]
De la part de Christian Damus
Envoyé : mardi 10 janvier 2017 12:31
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Dependency on Core Papyrus
Actually, this is a good point.
That fix for connector ends post Neon.2 is required for capsule structure inheritance to work. Without this fix, a new connector created by the user will not be inherited by capsule subclasses until the editor is closed and reopened because the Connector edit
helper uses the wrong EFactory to create the ends.
To work around this in Papyrus-RT would require overriding the entire connector edit-helper.
On Jan 10, 2017, 04:02 -0500, Peter Cigéhn <peter.cigehn@xxxxxxxxx>, wrote:
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?
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.
On Jan 9, 2017, 07:46 -0500, Remi Schnekenburger <rschnekenburger@xxxxxxxxxxxxxxxxx>, 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.
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?
On Jan 9, 2017, 03:15 -0500, Remi Schnekenburger <rschnekenburger@xxxxxxxxxxxxxxxxx>, 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?
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.
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.
_______________________________________________
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
--
_______________________________________________
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
|
