Re: [papyrus-rt-dev] [Features] What should be the basic feature content

[Ernesto Posse <eposse@xxxxxxxxxxxxx>]

I agree. 

So if I understand, there are three related but different issues:

1) which "end-user products" (EUPs) (*) to offer, i.e. "plain Papyrus-RT", "Papyrus-RT + Codegen", "Papyrus-RT Full", others?

2) categorization and which features to include in each of these the "EUPs", and how they are nested, etc.

3) how are these EUPs to be provided: a) a collection of p2 repos, b) Oomph setup files, c) RCPs packaged as zip files, others?

(*) I know "end-user" might not be entirely accurate, but just for the sake of clarity and to distinguish from the other meanings of "product".

In relation to 1, it does sound like a good idea for offering alternatives, very much like there is an "Eclipse for X". I would suggest these for starters:

A. prt-basic (aka "plain Papyrus-RT") = profile + core + common + tooling (+ compare?)

B. prt-codegen (aka "Papyrus-RT for prescriptive modelling") = prt-basic + codegen + rts

C. prt-mixed (aka "Papyrus-RT with mixed graphical/textual modelling") = prt-codegen + xtext

Or some variations of these.

In relation to 3, the new build process does create both p2 repos and RCPs, but as far as I can tell, codegen+rts is not yet included in the RCPs, but change 81898 seems to address it. Although the end product looks like it would be like B or C above. So perhaps we need separate .product files?

As for Oomph, I also like it, but it has two problems: 1) we need to keep it in synch with the other EUPs, and 2) it looks like it is rather brittle in that if you happen to be updating when one of the dependencies repos is unavailable, then the whole thing crashes, and you have to try again later (and cross your fingers that there isn't a Papyrus build running). So I think we should still keep offering this, but I think we should be providing the alternatives, namely the p2s and RCPs. Besides, if I recall correctly, I think Christian also had some arguments about this. Maybe Christian can comment?

On Tue, Sep 27, 2016 at 6:55 AM Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

Well, now we get into a completely new "dimension" compared to the original question. Now we also talk about the category into which the features are put. And I cannot agree more. I find it extremely confusing that the "nestedness" that you can see *after* you have installed a feature is not really the way the the feature are displayed in this dialog that you show here from "Install New Software". And as you point out, the top level feature is found "in the middle" of all the other features. So you really do not see at all that it is a top level feature that actually includes other features.

So we are now really talking about several different things at the same time. 

1) Features, and especially top level features which includes other features.

2) Categorization/grouping which is presented when selecting users select "Install New Software".

But in general I think that we are back to my concern: How do we really expect users to consume Papyrus-RT? Should we continue providing using an Ooomph product setup file together with the Eclipse Installer (which is the main recommended way currently)? Should they download an RCP package, i.e. basically a .zip-file which they unzip? Should they use "Install New Software" as shown by Célines screen shot? Probably all the previous ones? Which should focus and put most effort in? Which scenarios should we focus our testing on?

Consuming via "Install New Software" is just a pain in general, so I am not fully sure how much we really should spend on making that an optimized user experience. Personally I am totally hooked in Oomph, and since I have started using that I have never ever used "Install New Software". But that is probably just me... :)

And as usual we have different kinds of users, e.g. users doing the installation for themselves, tool-smiths creating custom made configurations, which we also need to consider. I foresee that providing an example Oomph setup file is still something that we will do, which can be used as a "template" for tool-smiths who want to extend/modify for their own specific configurations. Sure, the categorization is useful also for tool-smiths, since you for example also see the grouping into categories when using the Oomph Repository Explorer, which is pretty useful when creating setup files.

Depending on the users, the different kinds of "lego pieces" and larger "lego blocks" are probably different depending on if you consider end-users that do the installation for themselves, or tool-smiths creating custom configurations for their end-users to consume.

One major benefit I see from the larget "lego block" (feature including other features) is that we can add new dependencies, e.g. as we have done with the top level Papyrus-RT feature, without impacting existing Oomph setup files. They by magic get the included feature. That is the main argument I have for providing a top level feature for C++, which includes both the code-generator and the run-time. If we for some reason adds an additional feature which is highly related to C++ as a target language, we simple include this one and users will get this automatically without having to update their setup files.

/Peter Cigéhn

On 27 September 2016 at 12:20, Céline JANSSENS <celine.janssens@xxxxxxxxxxx> wrote:

Here is what we have now in the “Install New Software”

 

 

For example, you can see the main feature in the middle of the other ones , this is too confusing, and maybe we should create a specific category for it.

And the content of this feature is not clear. Categories can make it organized. As following:

 

·         Papyrus RT (Package)

o   Papyrus RT Basic

o   Papyrus RT Full

·         Papyrus RT (Detailed Features)

o   Papyrus RT Tooling Feature

o   Papyrus RT RSA-RTE Feature

o   Papyrus RT Profile Feature

o   …

 

 

I’m waiting for your suggestion ;)

 

Céline

 

 

De : Céline JANSSENS
Envoyé : mardi 27 septembre 2016 12:01
À : Peter Cigéhn <peter.cigehn@xxxxxxxxx>; papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Cc : Papyrus <papyrus@xxxxxxxxxxx>
Objet : RE: [papyrus-rt-dev] [Features] What should be the basic feature content ?

 

Thanks Peter for your feedback.

 

To answer about another top-level feature including Codegen and C++, in my opinion, we have to think about how clear it would be for the final user to understand what is included, what is not, what should be added on top, …

Often, I’m lost in the number of features available for an Eclipse Project into the “Install New Software” list. And I never know exactly what is contained in the feature.

 

Maybe the job is to clarify what we want as output (based on the users profiles) , to parametrize the different “packages” of features, p2 categories and products… made available.

 

What is given to the final user ? A executable Standalone?  A basic Eclipse where he has to install the different features required to have a customized Papyrus RT ?

 

As you said Peter, do we want to provide “Lego-Pieces” to be able to customize each configuration to each user need (migration, c++, xtext , compare, codegen ,… ) ? Or do we provide big  “Lego-Blok” with everything contained for the 2 or 3 users profiles ( Basic Papyrus RT, Papyrus RT with Codegen, Papyrus RT Full, … )?

 

I cannot answer this question, depends on your “product management” !

 

 

Best regards

 

Céline

 

 

De : Peter Cigéhn [mailto:peter.cigehn@xxxxxxxxx]
Envoyé : mardi 27 septembre 2016 09:31
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Cc : Papyrus <papyrus@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] [Features] What should be the basic feature content ?

 

Hi,

 

It probably should be Céline who should respond to this, but if I interpret Céline's original question (and what I originally responded to), this is more related to the features, and dependencies between features. 

 

To make it concrete it a bit more concrete. If you select Help > Installation details you get the list, or actually a tree, of features that is installed. A feature can be "flipped open" to reveal what other features it includes/depends on, in practice building up a dependency tree between features.

 

Here is it how it currently looks like for the tester setup. I "flipped open" the top level Papyrus-RT feature, which I assume is the one that Céline refers to as the basic feature.

 

 

From the tool-smith perspective, e.g. someone who puts together his own Oomph setup file, it is only needed to include this top level feature in the setup file, and the included features gets installed "for free". This is also how it works for the "Papyrus UML" feature. If you flip that one open, you will se a long list of included features.

 

To me, Célines question is about what "lego pieces" or larger "lego blocks" is that we shall provide tool-smiths, building up their own Papyrus-RT configurations, for all different kinds of purposes and scales, e.g. the core usage including code-generation run-time, systems modeling with only structure modeling without code-generation and run-time, building your own DSML on top of UML-RT and so on.

 

As I already have responded I feel that the current set of included features are "good enough". For someone setting up a very basic setup of Papyrus-RT, they should only have to include this (single) feature in their setup file.

 

Whether the compare feature shall be included or not can be debated. But I still feel that this one is kind of optional. I guess there could be scenarios where you have user's who don't work in a team, without version control (don't have EGit/JGit installed). So to me it is perfectly okay that this one is an optional "top level" feature on its own (as can be noted above, the tester setup actually still lacks the compare feature).

 

But as I already indicated earlier (including my picture that I now have quoted a number of times), and Charles also in his response, it would be nice to have some additional top level feature which includes both the C++ default language,code-generator and run-time. I would assume that from a tool-smith perspective, putting together a setup file for Papyrus-RT with C++ code-generation and run-time, would benefit from only having to include one top level feature for "C++", and then get everything needed "for free".

 

/Peter Cigéhn

 

On 26 September 2016 at 17:25, charles+zeligsoft.com <charles@xxxxxxxxxxxxx> wrote:

I actually added more information in the bug mentioned by Ernesto, below.

 

Basically, we need to align the product management vision and the product/project engineering artifacts. One of the problems, as eloquently stated by Peter in the bug, is that we have many usages/definitions for “product” and we need to harmonize this so we can more effectively communicate. We are, after all, breaking new grounds at Eclipse by doing product management…

 

This is what I wrote in the bug, for the Zeligsoft folks are still locked out:

 

 

I agree that it is a problem, and one that is fairly common when dealing with cross-functional teams.

I will take the action to clarify the content of the MVPs, which assumed incremental functionality on top of previous milestones.

There is also a need to properly define the requirements for installation(s), including optionality. The work you (Peter) had done on componentisation and sent through the Papyrus-RT developer mailing list is a good start to this effort.

Finally, there is a need for the development team to provide better education as to this o.e.papyrus-rt.product/papyrusrt.product file, its capabilities, and its use in the build and installation process - at least, I would benefit from such an explanation.

Once all this is understood, we will all be better equipped to have a coherent, shared understanding of where we are going.

In the meantime, please see inline below.

 

 

On 2016.09.26, at 10:54 , Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:

 

 

I think the discussion in Bug 502133 covers it.

 

So there are different meanings of "product", and Céline, correct me if I'm wrong, but I think you are asking about the "product" in the sense of what we package and deploy, as specified in the papyrusrt.product file, is that right?

 

My understanding from the discussions with Charles and Simon and in the bug, is that codegen and rts should be there for 0.8  (although not xtext), even if they are not considered the "base" set of features in some sense. I think this makes sense, because otherwise there would be a mismatch between what is installed by the Oomph setup and this packaged product. Furthermore, if a user downloads this product she would have to explicitly add the codegen update site to get the same set of features. 

 

PS: I'm responding here rather than in the bug because we are having connectivity issues with the Eclipse servers from our office.

 

--

Ernesto Posse

Zeligsoft

 

 

 

 

 

 

 

 

On Mon, Sep 26, 2016 at 6:17 AM Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

 

I think that the current included features in the the basic Papyrus-RT feature is what should be there. So that looks good to me.

 

The picture that I drew way back, https://dev.eclipse.org/mhonarc/lists/papyrus-rt-dev/msg00215.html, I still feel is highly relevant. 

 

What is missing in that picture is the optional migration, compare and Xtext features.

 

What I would like too see is the code-gen and run-time features to be included in some top level C++ feature. If that is the current C++ core feature, or a new C++ feature, which then includes the current C++ core feature and the code-gen and run-time features I cannot say. But this should be anyway be separated from the basic Papyrus-RT feature (as indicated in the picture).

 

/Peter Cigéhn

 

On 26 September 2016 at 10:26, Céline JANSSENS <celine.janssens@xxxxxxxxxxx> wrote:

Hello Everyone,

 

Could you please let me know how the different features should be organized. I mean, what the basic Papyrus RT feature should include ?

 

Here is what is into the papyrus rt feature for the time being:

 

·         Oeprt.umlrt.common.feature

·         Oeprt.umlrt.common.ui.feature

·         Oeprt.umlrt.core.feature

·         Oeprt.umlrt.tooling.feature

·         Oeprt.umlrt.profile.feature

 

<cr>

This is a good list of basic features. The only other basic feature I could see in here would be “Oeprt.umlrt.tooling.compare.feature” because I see this as a rather important aspect of any development and especially for the proper support of a DSML.

</cr>

 

Are not include by default:

 

<cr>

What do you mean by “not included by default”?

From the definition of the product (Eclipse project page), some of these will need to be included in the final (product management) product.

Some of these are also part of the previous milestone and not providing them could be considered a regression, unless we ensure that proper installation warnings and documentation is provided (e.g., a warning that some parts are now optional or explicitly showing what is to be installed or not where user discovery of these options is not optional). According to the Eclipse guidelines, this is something that can be done in a minor version change, but we need to ensure that it is very visible and transparent. Given the v0.8 timeframe, I would prefer that this installation change be done in v0.9 or 1.0, where we would have more lead time to “educate” our users.

</cr>

 

·         Oeprt.umlrt.cpp.feature

·         Oeprt.umlrt.migration.rsa.feature

·         Oeprt.umlrt.tooling.compare.feature

<cr>

See above… 

</cr>

·         Oeprt. codegen-feature

·         Oeprt.rts-feature

·         Oeprt.xtumlrt.xtext.feature

<cr>

I would probably group some of these together. for example, everything related to generating an executable for a particular language. However, I am not sure if that matches the meaning of the features from a  development team point of view...

</cr>

 

 

Keep in mind that all the features are still available in the p2 to be installed separately.

The basic feature should contain the core part of Papyrus RT, and should work on his own !

<cr>

What do you mean by "work on his [sic!] own”?

If you mean the minimum configuration that would let you create a UML-RT model, that is probably correct.

From the project definition and what was provided in v0.7.2, I would expect to be able to create a UML-RT model, to generate its code, and to compile and run it, which would not be the case with only the basic features as described above.

On the other hand, I can see the future need for the basic set as described above (e.g., to have a “Papyrus-RT for DSML toolsmiths” variant).

</cr>

 

This organisation is nothing related with the product that can contain several features, basic one and others…

<cr>

Understood. However, we still need to make the link between the (product management) product and this (engineering) product.

</cr>

 

Which features  need to be included into the basic papyrus-rt feature and is not ?

 

Best regards

Céline

 

 

 

 

_______________________________________________
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

<image001.jpg>_______________________________________________
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

 

 

Vous recevez ce message, car vous êtes un membre abonné au groupe Papyrus.
Afficher les conversations du groupe | Afficher les fichiers du groupe | Annuler l’abonnement

 

_______________________________________________
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