Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Update the Model Import tool for Neon
Hi Peter,

Thanks for the feedback.

Note that the manual installation process as only been kept around for “legacy” purpose. It will likely no longer exist once 1.0 is released.

And yes, the importer is not part of 1.0, and my comment was broader than that single version.


Sincerely,

Charles Rivet
Senior Product Manager
charles@xxxxxxxxxxxxx

On 2016.04.11, at 10:47 , Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

I we want to make the import tool available for those that use the Eclipse Installer, as described on the Wiki, https://wiki.eclipse.org/Papyrus-RT/User_Guide/Eclipse_Installer, then we simply add it to the setup file. For those users, we can ensure that they get without having to bother.

For users that follow the manual instructions at https://wiki.eclipse.org/Papyrus-RT/User_Guide/Installation, they will actually also get it (as the instructions is currently written), since they select to the top level Papyrus-RT category (which includes all features, disregarding if they are included in the top level Papyrus-RT feature or not).  Apart from that we have the confusion that we need to install from two separates repos, but that I guess is something that we are about to fix eventually.

The only discussion here is that the top level Papyrus-RT feature, that currently only includes profile, core and tooling (and which does not include the codegenerator and the runtime either), does not reference the import tool automatically.

We actually have the same for the current Papyrus-RT Core C++ Feature (which Christian pointed out on the discussion we have had related to the Gerrit path set for the Oomph-setup file) don't do anything right now. This one is not included in any top level feature either, but it is included in the Papyrus-RT category when selecting that in the p2 installer. So that one is also installed if you follow the manual installation steps on the Wiki.

/Peter Cigéhn

PS. Earlier we have had a discussion about the maturity of the import tool, and when we released 0.7.0 - 0.7.2, we never included the import tool since we considered it too immature. I see the same now, and as we have said (if I remember correctly), the import tool is not included 1.0. So we should have it "optional" for now also and not "force" it onto any users until post-1.0. DS.


On 11 April 2016 at 16:26, charles+zeligsoft.com <charles@xxxxxxxxxxxxx> wrote:
I agree with the RSA-RTE importer being a feature, but I have a problem with defining it as an _optional_ feature by default.

Yes, this is not a feature that would be used very often once existing models have been imported. However, it does have an impact on users trying the tool for the first time. One of out needs is to make it easy for RSA-RTE users to migrate (especially those who are not part of this team and who may not be aware of this discussion).

We _are_ positioning Papyrus-RT as a tool supporting a UML-RT DSL and as an RSA-RTE replacement. So:

  • What kind of UML-RT DSL tool would not have a readily available importer from the only other UML-RT tool?

  • And then,  what if an existing RSA-RTE user (and yes, there are some non-Ericsson companies out there still using RSA-RTE) decides to have a look at Papyrus-RT and cannot easily find an importer after downloading the software?

Yes, you can argue that the importer is “readily” available as an additional component, but that user above may not be familiar the way Papyrus deals with additional components.

A question:

  • Could this be handled through the installation process/tool? That his, having the default product includes the importer, but allowing knowledgeable be able to leave it optional? Can OOMPH provide this level of configurability?

And a comment:

  • Related to this, we need a “Getting Started” link on the “Welcome” window, and this topic must be in there. However, long-time users of Eclipse may just power through that screen...


Sincerely,

Charles Rivet
Senior Product Manager; Papyrus-RT product manager
charles@xxxxxxxxxxxxx

On 2016.04.11, at 08:19 , Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

Good questions. Regarding the builds I personally have no opinion about that, since I do not understand or have insight in the implications of the different choices.

When it comes to the features, I have actually been thinking about exactly the same.

I realized for example that I had missed the Papyrus_RT Core C++ Feature, which is not included in the top level Papyrus-RT Feature either. This makes perfect sense also, since the bringing in the specific language feature should be optional (depending on which languages we should have). We had a discussion in the mailing list a while ago, about exactly this, and I made a simple picture back then

<image.png>

I guess in the same way as we want to keep the C++ (or C or Java and so on) as optional features, we should also have the import tool a separate feature, not included in the top level Papyrus-RT Feature.

So I would propose to move the new import feature as separate feature as well. If you have the need to import old RSARTE models, then you need to check one additional feature (apart from the action/target language that you want to use).

/Peter Cigéhn

On 11 April 2016 at 14:08, LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:

Hi,

 

I’ve pushed a new patch set to include the RSA-RTE importer in a separate feature. However, this raises some additional questions:

 

-          Currently, we have 3 builds and 3 features:

o   Profile

o   Core

o   Tooling

 

It seems that the RSA Importer makes sense in the Tooling build, but not in the tooling feature. Thus, the new patch set adds a new feature (RSA Importer) included in the Tooling build. Should we configure a separate build for this?

 

-          I’ve added the RSA Importer feature to the top-level Papyrus-RT Feature. Does that make sense as well? If the end-user doesn’t want to install the RSA Importer, then he needs to manually check Profile + Core + Tooling, without the RSA Importer. But the top-level feature is supposed to contain everything else, so... not sure what’s best

 

Regards,
Camille

 

De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de LETAVERNIER Camille
Envoyé : lundi 11 avril 2016 09:54
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : [PROVENANCE INTERNET] Re: [papyrus-rt-dev] Update the Model Import tool for Neon

 

Hi Peter,

 

Ø  maybe we should put this into its own feature, instead of including it directly in the tooling feature

 

I have no opinion on this, so, whatever the Papyrus-RT team prefers :) I’ll add a separate feature

 

Ø  When the RSARTE specific import extension is installed, do you also have to install the RSA import feature from Papyrus? Or will the RSA import functionality included automatically?

 

The standard RSA Import from Papyrus is automatically installed when installing the Papyrus-RT Import (provided that the Papyrus Extra update site is available, so this depends on your deployment). The extension adds no extra UI, it works exactly in the same way (Except that it adds support for Papyrus-RT rather than discarding the profile and stereotypes). Additional UI might be required if e.g. the RSA-RTE Import needs specific import options. But so far, this didn’t seem to be a use case

 

Regards,
Camille

 

De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Peter Cigéhn
Envoyé : lundi 11 avril 2016 09:27
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Update the Model Import tool for Neon

 

Hi Camille,

 

As I commented on the Gerrit change, maybe we should put this into its own feature, instead of including it directly in the tooling feature? Since the import tool is a rather "one-shot"-kind of functionality, I guess it would be good if it could be installed optionally for those that don't want/need it. The new import feature could still be included in the top level Papyrus-RT feature in the same way as profle, core and tooling is already.

 

For my understanding also: When the RSARTE specific import extension is installed, do you also have to install the RSA import feature from Papyrus? Or will the RSA import functionality included automatically?

 

In practice, how will it work from an end-user perspective? Will it be the different sets of import options in the import wizard, or do the RSARTE specific import just extends the existing RSA import function, in practice causing it to to be able to also import RSARTE models?

 

/Peter Cigéhn

 

On 7 April 2016 at 13:06, LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:

Hi all,

 

A few months ago, the Model Import tool in Papyrus (Neon) has been refactored to support extensions. The UML-RT part has been removed from the Papyrus plug-in, and contributed to Papyrus-RT. The patch was waiting for the migration of Papyrus-RT to Neon, which is now complete (At least for the tooling part, which is affected by this patch)

 

I’ve rebased the patch to the latest master, so it’s now ready to be merged. Just a few remarks:

 

-          The patch contributes a new Tooling plug-in and the associated Test plug-in, in version 0.8.0. Papyrus-RT still seems to be in 0.7.2

o   That’s not an issue, but maybe we want to remain consistent

-          The patch only adds new plug-ins, and doesn’t change any existing file, except:

o   Tooling pom.xml (Addition of a new module)

o   Tooling Tests pom.xml (Addition of a new module)

o   Tooling Feature (Addition of a new plug-in)

 

So I don’t expect any (major) conflict with other contributions

 

483828: [Model Import] Extend the Papyrus Migration Tool to support UML-RT models

https://bugs.eclipse.org/bugs/show_bug.cgi?id=483828

 

62188: Bug 483828: [Model Import] Extend the Papyrus Migration Tool to support UML-RT models [Id2d75c74]

https://git.eclipse.org/r/#/c/62188/

 

Camille


_______________________________________________
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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Back to the top