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

[Peter Cigéhn <peter.cigehn@xxxxxxxxx>]

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