[
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
|
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...
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
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxxTo 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