Hi, Ernesto,
On the subject of Oomph: the intermittent availability of repos should not be an issue for product releases via Oomph. These release setups would only ever reference release repositories, which are static. The concern I have in shipping Papyrus-RT packaged products via Oomph is just that it’s not as simple a solution for users. With an RCP package, they just download, unzip, and go. Of course, the considerable advantage of the Oomph solution is the p2 bundle pool. That’s a miracle for disk space, but even that is only really so valuable for developers who update their PDE Targets from time to time and so would otherwise have this multiplicative factor of (workbench downloads) x (PDE targets). What I would most like to see is a single-sourced generation of both the product setup models for Oomph and the product definition files for RCP. This should not be difficult. I would happily volunteer to develop some tooling for this.
ChristianOn 27 September, 2016 at 13:57:00, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
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?
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.
_______________________________________________
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
|