Re: [mdt-papyrus.dev] Papyrus in the Modeling EPP (was Re: Eclipse Oxyge

[Cédric Brun <cedric.brun@xxxxxxx>]

I don't want to hijack this mailling-list so let's move the discussions either in specific tickets or on the modeling-pmc mailling list if anybody is willing to spend some time in improving those integrations (or even the #eclipse-modeling channel for direct exchanges).

Several initiatives currently under work might be of interest to you (the scope if 5.0 is quite accurately reflected by this page [1]):

Sirius 5.0 (with Oxygen then) will provide an editor (as in the Eclipse definition) for .aird files , with the intent to fix those "Package Explorer" vs "Model Explorer" major irritations. Bugzilla is #510040, this has been presented as part of the roadmap during SiriusCon ([1] for the corresponding slide)
More flexibility will be provided regarding persistence of representations (bug 493353)
There is no such requirement to have "everything in a single file" nor to use the nature if you don't want to.

> I am very interested in allowing a UMLX file to be maintained in a conventional fashion; double-click on a *.umlx

This has been possible from day one but not very documented as this feature has not been used a lot. You can define an Eclipse editor for your model extension and then "manage yourself where the representations should be kept". If you start using it, have a look on org.eclipse.emf.ecoretools.design.ui.editor.EcoreEntitiesReadOnlyEditor for an example in EcoreTools and feel free to open bugs.

[1] https://projects.eclipse.org/projects/modeling.sirius/releases/5.0.0/bugs
[2] http://cedric.brun.io/talks/SiriusCon2016/slides/#/5/5


Le 25/01/2017 à 10:43, Ed Willink a écrit :

Hi Cédric

Apologies, I was using WinZIP to examine EPP contents and saw many Sirius packages and so wrongly assumed that Sirius was included.

I certainly support the use of canned screen organizations to help new users, but my understanding of perspectives is that I can create my custom role-specific perspective by selecting and arranging what matters to my specific role. The views that make a particular CASE perspective good, should be available to my perspectives too. Additional CASE views should not needlessly duplicate/conflict with more standard views. So I find the Navigator View and Model Explorer View a pain since they provide vastly inferior (no Working Sets) Package Explorer View functionality but are necessary because they have an added capability; the bin tree / model content. Do you ever use the Project Explorer View?

If we could merge the Model Explorer into the Package Explorer, one of my major irritations with Papyrus and Sirius would vanish. There would then be a stronger incentive to make the standard way of working apply to modeling. Custom/canned perspectives should be straightforward.

However to really achieve some uniformity we need some consensus on model indexing. Currently the only consensus seems to be that 'my' index is good, 'your' index is rubbish. Xtext does something wierd that never helps me, proactively burns CPU, and generally encourages me to minimize the number of plugins with an Xtext nature. Sirius seems to need to have everything in a single file that is updated flakily and too lazily. Epsilon burns time. The indexing project failed. JDT seems to be joining in with a new CPU burner. Papyrus is less of a problem since it doesn't really use Ecore files. I suspect that Sirius is closer to being 'right'; lazy, but why all in one file?

With a Sirius-based UMLXforEcore appearing in M5, I am very interested in allowing a UMLX file to be maintained in a conventional fashion; double-click on a *.umlx file in the Package Explorer without adding any natures. IMHO a nature facilitates building, not basic editing.

    Regards

        Ed Willink

On 25/01/2017 08:43, Cédric Brun wrote:

Sirius is not in the modeling package, it has to be installed explicitely through the update site or the "Modeling discovery".  Please check whatever you think is reality before spreading "alternative facts".

There are parts of the runtime which are pulled down by EcoreTools but that's it, there is no "Sirius" perspective in the modeling package or any Sirius specific wizard to specify a tool using Sirius, the only reference to Sirius you can find is the wizard category allowing to create "Modeling Project" or "Representations Files" which are needed by Ecore Tools.

My position regarding perspectives is that I'd like them to be user and activity focused and not "product" or "technology" focused. Hence a "Modeling" perspective is fine, a "Sirius" perspective is not. An "Ecore" perspective is also in the package right now for "legacy" reasons as users were used to it, I'm still undecided about what to do with this one.

A global (at the Eclipse Modeling Project scale) initiative to standardize on a few key perspectives and category would get my complete support, it just did not happened yet because no other project has expressed interest in doing this, technically it would seem fairly easy: we just have to standardize on id's and names and potentially build a few plugins hosting those.

Any interest?

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
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