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?