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
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".
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.
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.
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.
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).
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>
</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 !
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).
This organisation is nothing related with the product that can contain several features, basic one and others…
Understood. However, we still need to make the link between the (product management) product and this (engineering) product.
_______________________________________________
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
|
