| Re: [papyrus-rt-dev] Status of RT Model Migration (Import) in 1.0 |
Hi,Well, considering the status of the RSARTE import tool (disregarding this discussion about the status of what it depends on), I would not like to see it leave incubation. I don't think that the import tools is mature enough to let it leave incubation.To be honest, I am not sure that I think that the RSA import tool should leave incubation either, and from my earlier understanding, it would still be in incubation. I guess the version numbering just follows along the old version number from when it was part of the extras components of Papyrus for which a lot of them left incubation too early. This as I have understood is what they have tried to correct with moving out stuff into separate repos, e.g. the incubation repo for stuff that really should be incubation. I also thought that the interoperability repo would be in incubation. But I guess this is something that really needs to be checked with the Papyrus project if it really have left incubation already.Anyway, the discussion we have had so far has been to leave RSARTE migration in incubation. See for example the discussion in bug 513384 where we left the wording "Incubation" for the RSARTE migration feature.But I am probably not the right one to make this call whether it should graduating or stay in incubation. Personally I think we will send the completely wrong message to the community if we stated that it was graduating, because it is not mature enough and people would just get the wrong expectations if we did graduate it prematurely./Peter CigéhnOn 21 June 2017 at 15:52, Christian Damus <give.a.damus@xxxxxxxxx> wrote:Hi, Camille,Thanks for the clarification. Indeed, I thought for some reason that the whole Papyrus Interoperability project was in incubation. There may have been some talk of releasing the Papyrus-RT RSA-RTE Migration component as incubation only for this release, I’m not certain now. Perhaps Charles or Simon can comment on that.In any case, probably this means that we can proceed with your gerrit patches. Are we all agreed on that?
Cheers,
Christian
On Jun 21, 2017, 09:30 -0400, Camille Letavernier <cletavernier@xxxxxxxxxxxxxxxxm >, wrote:
Hi Christian,I'm not sure this is an issue of "Incubation vs non-incubation", as Papyrus/Interoperability is not "incubating". It's just "not released yet" (i.e. no stable update site, and I'm not sure about release review/ip log, since this should also be done at the project level)The plug-ins we are using for the Model Migration are:- Papyrus Interop: "RSA to Papyrus Import tool" (v1.4.0, not released)- Papyrus: "Papyrus M2M QvTo Common Plugin" (v1.0.0, released)- Papyrus: "Papyrus UML M2M QvTo Common Blackboxes Plugin" (v1.0.0, released)- PapyrusRT: "Papyrus-RT UML-RT Profile" (v0.9.0, incubating)So unless I missed one, none of them is actually incubating (Except the PapyrusRT profile, but it would graduate at the same time as the Model Import tool - or even before that)Most of these plug-ins are part of the Papyrus Main plug-ins, so there's only one plug-in missing, which needs to be officially released on the Papyrus side(Or is there also a debate about whether the Papyrus RT migration tool itself should be incubating or graduating?)Cheers,Camille______________________________
On Wed, Jun 21, 2017 at 3:00 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Nice work, Camille. It looks like all of the bits are in place to restore the migration feature.However, we still need to come to a decision on how to proceed. If we intend to graduate with a 1.0 release, then AFAIU it’s an all-or-nothing deal. No part of that release may be in incubation. So, if the migration component is to release as a 0.10 then it will have to be a separate build with a separate deployment and installation from a separate p2 repository. (note that version numbering doesn’t have to correlate to incubation status, but it is helpful to users)Otherwise, if we want to graduate the migration feature too, then of course its dependencies in Papyrus must be released as non-incubation, too.The EMO’s Wiki page about incubation talks exclusively in terms of Project. The migration component is not a Project; Papyrus-RT is. Has anyone discussed the details of our plan with Wayne/EMO? Maybe it only matters to conform to the Incubation guidelines if we wanted to use the parallel IP process, which we don’t?
Cheers,
Christian
On Jun 21, 2017, 07:36 -0400, Camille Letavernier <cletavernier@xxxxxxxxxxxxxxxxm >, wrote:
Thanks, Christian!It took me some time to figure out how the build was configured (I initially thought the migration was part of the tooling, but that's not exactly true :) ), so your rebase probably cleans up a few things :)This commit was part of a commits chain, so I've rebased the other 3 commits on top of it. The Gerrit-Migration build should be green after thatCamille______________________________
On Tue, Jun 20, 2017 at 5:02 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Camille,Thanks for working on this! As I merged today some changes in the TPs that conflicted with yours, I took the liberty of rebasing your change 99631 to re-generate the TPs and I’ve re-enabled the Migration component Gerrit build to verify the TP at least.
Cheers,
Christian
On Jun 20, 2017, 05:14 -0400, Camille Letavernier <cletavernier@xxxxxxxxxxxxxxxxm >, wrote:
Hi,The model migration for Papyrus-RT is mostly fixed. It will depend on a release of the "Papyrus Interoperability" component(s) for Oxygen. The releng part is also ready I think, although the Gerrit job for migration is disabled, so I can't test it online (Currently, the releng relies on the hudson/nightly update site from Papyrus Interop).Camille______________________________
On Mon, Jun 19, 2017 at 5:12 PM, Camille Letavernier <cletavernier@xxxxxxxxxxxxxxxxm > wrote:
Hi,
I've opened Bug 518469 to investigate the migration status. If the migration doesn't need any fix on the Papyrus side, then we could perhaps reuse the Neon bits (Although this wouldn't solve the "incubation" issue, but at least the neon plug-ins are 'released'). If some work is required on the Papyrus side, then we'll see what it would take to release somethingCheers,Camille
On Mon, Jun 19, 2017 at 5:02 PM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi,As far as I can tell, there isn’t going to be an Oxygen release of the Papyrus Interoperability component that delivers the RSA Migration infrastructure. I don’t see any repository on the download server that would provide this, and the nightly build (currently disabled) of the Papyrus-RT migration component gets the Papyrus bits directly from the Papyrus Interoperability Hudson build job.If I’m wrong, please somebody tell me where the Papyrus Interoperability release repository will be. Otherwise, there’s no question of releasing a Papyrus-RT migration feature, even as incubation, because it cannot use unreleased software.
Cheers,Christian
On Jun 19, 2017, 10:54 -0400, Camille Letavernier <cletavernier@xxxxxxxxxxxxxxxxm >, wrote:
Hi,
I'm not sure exactly what the intention is, and I've not looked into the details of the failure. My naive assumption at this point is that the transformation "mostly works" (From RSA to Papyrus-RT Neon), except for the references to the Viewpoint prototypes (Which, I believe, break very early and very badly, probably preventing the rest of the transformation from even starting)
So we could simply replace the broken references, then let run the RSA to Papyrus/RT transformation as-is (Targetting Mars or Neon format), then rely on existing reconcilers to transform the individual diagrams from Mars/Neon to Oxygen (As we did for the Mars -> Neon transition)Since I'm still not too sure about the changes which occurred this year, there could be more issues. But fixing the broken viewpoint references is a mandatory first step anyway (I don't know if it also requires fixing in Papyrus, if there are viewpoint-based diagrams handled by the Papyrus transformation)Camille______________________________
On Mon, Jun 19, 2017 at 4:31 PM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
Hi,Yes, there are some work, not only related to releng, related to the RSARTE model migration (import). See some discussion about it in bug 517688 where it was decided to write a new bug for the work regarding restoring the tests for RSARTE model migration (import). But this has not been done so far (I had hoped that Rémi or Camille could write such a bug since I did not really know how to formulate it). I guess that bug also should/could cover the releng aspects...Personally I think that we should try to provide what we have related to the RSARTE model migration (import) with a little effort we can to get it working again. It should still be in incubation (since it depends on the RSA model migration (import) tool which from what I have understood also still is in incubation). So we need to keep the RSARTE model migration (import) "separate" from the stuff in Papyrus-RT 1.0 that will leave incubation./Peter Cigéhn
On 19 June 2017 at 16:15, Christian Damus <give.a.damus@xxxxxxxxx> wrote:______________________________Hi, Team,In looking through the Target Platform definitions for the Papyrus-RT build, I see still that the Papyrus RSA Migration feature dependency is commented out in various places. This was done originally because when we moved onto Oxygen, there was an interval in which viable builds of this component were not available from Papyrus.But, also, judging from activity on migration-related bugs, it seems that RSA-RTE model import was back-burnered for the 1.0 release. Are we intending to ship the RT model import feature in 1.0? Because, if so, I have some releng work to do to restore it.
Thanks,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
--
Camille Letavernier
Senior Software Engineer
EclipseSource Paris
Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19
Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau
General Manager: Rémi 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
--
Camille Letavernier
Senior Software Engineer
EclipseSource Paris
Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19
Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau
General Manager: Rémi Schnekenburger
--
Camille Letavernier
Senior Software Engineer
EclipseSource Paris
Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19
Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau
General Manager: Rémi 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
--
Camille Letavernier
Senior Software Engineer
EclipseSource Paris
Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19
Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau
General Manager: Rémi 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
--
Camille Letavernier
Senior Software Engineer
EclipseSource Paris
Email: cletavernier@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
Fax: +49 89 21 555 30 - 19
Palaiseau-Entreprises
7 rue de la Croix Martre
91873 Palaiseau
General Manager: Rémi 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