Bug 470297

Comment 1 Max Bureck 2015-08-21 14:29:26 EDT

I have the same problem, the labelFormat property now has the cardinality of 0..4 and is ordered and unique. So I should be able to assign an OrderedSet to the property, which does not work. I will attach a sample project. Open the diagram in the "model/TestMe.aird" file and you will see that the style customization throws an exception with the message "The value '[bold, italic]' is not a valid enumerator of 'FontFormat'".

Comment 2 Max Bureck 2015-08-21 14:30:53 EDT

Created attachment 256024 [details]
Example project showing problems with syle customization for BasicLabelStyleDescription::labelFormat property

Comment 3 Eclipse Genie 2016-03-21 09:22:49 EDT

New Gerrit change created: https://git.eclipse.org/r/68901

Comment 4 Eclipse Genie 2016-04-25 08:00:10 EDT

Gerrit change https://git.eclipse.org/r/68901 was merged to [master].
Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=d5f32547b60d19b08be6b68ff45fd5206712f6cd

Comment 5 Cedric Brun 2016-05-09 10:48:17 EDT

This introduced a regression detected thanks to EcoreTools.
- drag&drop an EClass having at least one required (1..1) attribute in a diagram => nothing happens and the shapes does not appear in the diagram.

Such a required attribute is supposed to be displayed with a BOLD fontFormat, and EcoreTools uses the StyleCustomization for this.

What happens is that an ArrayStoreException is thrown during the refresh leading to a complete rollback.

Comment 6 Laurent Redor 2016-05-11 12:21:02 EDT

Cédric: In EcoreTools, the service must be like this now:

    public FontFormat fontFormatBold(EObject any) {
        return FontFormat.BOLD_LITERAL;
    }

instead of 

    public EEnumLiteral fontFormatBold(EObject any) {
        return ViewpointPackage.eINSTANCE.getFontFormat().getEEnumLiteral("bold");
    }

Comment 7 Eclipse Genie 2016-05-11 12:27:36 EDT

New Gerrit change created: https://git.eclipse.org/r/72543

Comment 8 Laurent Redor 2016-05-11 12:28:34 EDT

Cédric: The above gerrit corresponds to the proposed solution in comment 6.

Comment 9 Cedric Brun 2016-05-11 14:18:42 EDT

(In reply to Laurent Redor from comment #8)
> Cédric: The above gerrit corresponds to the proposed solution in comment 6.

This looks like a breaking change which might impact quite a few modelers and be fairly hard to detect. Why would that be necessary whereas it was not before ?

Comment 10 Eclipse Genie 2016-05-12 06:56:18 EDT

New Gerrit change created: https://git.eclipse.org/r/72608

Comment 11 Laurent Redor 2016-05-12 08:05:35 EDT

Yes, it can be considered as breaking change. The gerrit of comment 10 corresponds to a Sirius documentation update to notify these changes.

Your service worked before, because it was evaluated to a String value (bold) and then converted to a FontFormat.
Now the service is evaluated as Object (to allow list value, "bold AND italic" for example). There is no longer the magic "String conversion".

Comment 12 Eclipse Genie 2016-05-13 05:32:58 EDT

Gerrit change https://git.eclipse.org/r/72608 was merged to [master].
Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=407a3a24d89c963d1bc01ae0dce3ae732eed4eb8

Comment 13 Eclipse Genie 2016-05-13 05:45:58 EDT

Gerrit change https://git.eclipse.org/r/72543 was merged to [master].
Commit: http://git.eclipse.org/c/ecoretools/org.eclipse.ecoretools.git/commit/?id=f1b84f4ac842b1272297bf4c765bdb9f03b22960

Comment 14 Laurent Redor 2016-05-13 08:04:58 EDT

According to comment 9 the documentation of Sirius has been completed and the service in EcoreTools has been modified.

Comment 15 Florian Barbin 2016-05-26 05:23:13 EDT

Verified on Sirius 4.0.0.RC1

Comment 16 Pierre-Charles David 2016-06-24 08:00:34 EDT

Available in Sirius 4.0.0.