Thank for those details. I'll have to see whether I can't get all
of OCL and QVTd in for Oxygen.
Perspectives are one of my pet hates.
Papyrus has a perspective that seems to get in my way as a mostly
Java developer who also models.
Sirius has two perspectives that similarly get in my way. I have
yet to work out what the difference between the two is.
Surely Sirius introducing two perspectives violates the Amalgam
requirements?
IMHO, the requirement should be modified to allow perspectives,
but to prohibit the mandatory requirement to change to a
perspective for standard operations. e.g. New/Open Editor should
work from the Package Explorer (as well as Model Explorer).
I don't know if it's a frequently
asked question, I don't recall it's ever been asked to me anyway
(the package maintainer) apart from you 2 years ago, about
Xtext [1].
I'll give the very same answer I gave then
"
The rules are stated in more technical aspects there [2] ,
several projects complied with those rules and have been
included in the package, notably EMF Parlsey and EMF Client
Platform.
```
To be part of the base
platform a component should fulfill the following
requirements :
- alow UI
profile (only
a few actions, no perspectives..)
- small (including
non-packaged dependencies)
- being
a complementary framework to EMF or a tool
with a fairly small focus.
- being
already adopted by the community at
large
- part
of the simultaneous release and
fulfilling all therelease
train requirements
- not
being in incubation (NEW INDIGO)
- being
'lazy', when the package just got started and not feature of
your project have been used, none of your plugins should be
loaded. (NEW LUNA)
```
Those rules are failry easy to check and comply with for Xtext,
Parlsey or ECP, it seems Papyrus is a completely different beast
with more plugins and dependencies. You mention that it would
add more than 100Mb to the package, that would be a concern,
processes or classes loaded without even using Papyrus would be
more another point of attention but beside that: the potential
for integration issues is quite high and that would mean
thoroughly testing each milestone.
I did not used Papyrus lately so I have no idea how it would
fare regarding the UI profile.
With that being said, feel free to reach to me and open a
bugzilla if anybody from the Papyrus team is willing to get
involved and move down this path.
Cheers,
Cédric
[1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=445969
[2]
https://wiki.eclipse.org/ModelingAmalgam
Le 24/01/2017 à 16:00, Ed Willink a écrit :
Hi
I think this is an FAQ that has never had a good answer.
If the Modeling EPP includes Papyrus and Sirius, it will be
huge, which some people dislike.
If it doesn't include Papyrus or Sirius, is it a Modeling
package at all?
Until recently (Luna) the Modeling EPP didn't even include
Xtext, but checking on Neon I see that inclusion of the
replacement EcoreTool diagram editor means that EcoreTools,
Sirius, Xtext, Xtend, MWE2 are now all there. Xcore, Papyrus
and OCL editing are missing.
Luna changed the EPP from 300MB to 400MB. It looks as if
Papyrus would add 175MB directly and perhaps 25MB indirectly
through OCL?
Regards
Ed Willink
On 24/01/2017 08:20, LE FEVRE
FRANCOIS wrote:
Do you think it could pertinent to
re-introduce such packages with papyrus inside?
|
This email has been checked for
viruses by Avast antivirus software.
www.avast.com
|
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
--
Cédric
Brun
CTO
+33 2 51 13 51 42
@bruncedric
7 Boulevard Ampère - Carquefou -
France
obeo.fr
| twitter | linkedin
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev