[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-papyrus.dev] Notice: Papyrus Bundle Refactorings for Neon M6
|
Hi, Rémi,
Good to hear that the road is clear for this week. As it happens, the Gerrit change has grown quite a lot as it has ended up changing the line endings of almost all of the files in the repository (owing to the introduction of a .gitattributes file). Ultimately, I suppose this is a good thing; I’m just surprised that these weren’t already all converted last week when that file was first created.
Sorry about the block charts; I didn’t realize that copying and pasting everything from my markdown preview tool would produce hyperlinks to local files instead of copying the images. I attach them in a PDF for reference.
Yes, in brief discussion with Camille, it turned out that investing time into factoring the UML dependencies out of the palette service API (the concepts of profile and stereotype permeate the API to the highest, most abstract level) wasn’t worthwhile precisely because a new palette framework is planned for Neon.
Absolutely, the new palette configuration framework should be in the common diagram layer. I suppose it should also be compatible with both GEF3 and GEF4 palettes, which perhaps might imply some extra abstraction layers to plug in both of those technologies independently.
Cheers,
Christian
On 10 February, 2016 at 03:28:34, SCHNEKENBURGER Remi 211865 (remi.schnekenburger@xxxxxx) wrote:
Hi Christian,
Thanks for this update! There should not be issues
with committers plan for this week.
Concerning the palette, the major part of the
framework is located in UML layer, which is an historical issue.
Almost everything from the palette is agnostic of the UML language,
especially now with the paletteconfiguration framework that relies
on the element types. The palette configuration has a kind of
dependency to UML because of the ‘requiredProfile’ field in the
metamodel, but this field should be replaced by a ‘filter’ as
defined by the filter plugin, in the infra layer.
For the specific case of the xml based palette and
this css contribution, we unfortunately have no replacement for
post actions targeting notation objects for now. The xml based
palette providers should be deprecated in 2.0, as the Papyrus
toolsmiths should rather rely on the palette configuration model
than xml (better workflow and integration than the xml palette). So
for the css plugin, I think it is good to move it to UML, as all
the framework of XML palette is in UML layer, but I think palette
configuration plugins should be located in gmfdiag.common. What is
your opinion?
FYI, I could not read the pictures from your
message, I don’t know if Eclipse mailing lists are doing some
kind of filtering.
Regards,
Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
 www.eclipse.org/papyrus
_______________________________________________
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
|
Attachment:
PLA.pdf
Description: Binary data
