TL;DR: we’ve been working on a new query interpreter for Sirius which is small, simple, fast, extensible and bring richer validation. It’s been released for early adopters with Sirius 3.0 but will be the recommended interpreter for Sirius 3.1 in October. The MTL interpreter ([/]) will be deprecated at some point, this moment depending on how fast the community adopts the new aql: interpreter. Background and motivation One of the key factor making Sirius so flexible is the ability to rely on queries when defining your graphical mapping. Every configurable field rendered with a yellow background in the tooling specification editor can be set either with a literal value or with a query which will be interpreted at runtime. Sirius can be extended with new query interpreters through Eclipse plugins, each having its own prefix. AQL's Code completion within the .odesign editor Some interpreters are available by default notably feature:, var:, or service: which are direct access either to...

Today is a great day: with the announcement of Eclipse Mars, many great projects are released, and Sirius 3.0 is part of this release train. When I have a look at the status of the Sirius project today, one soundtrack immediately comes to mind: Harder, Better, Faster, Stronger Work on it harder One first fact, looking at the project’s statistics, is that the Sirius team worked hard on this release to deliver some new cool features and improve the existing ones: VersionDateTotal ClosedFeature Requests 1.0.0(Luna) June 14 100 2 1.0.1 Aug 14 20 - 2.0.0 Oct 14 113 27 2.0.1 Nov 14 2 - 2.0.2 Dec 14 15 - 2.0.3 Jan 15 16 - 2.0.4 Feb 15 8 - 2.0.5 Apr 15 8 - 3.0.0(Mars) Jun 15 213 35     426 64 This release is the first one on which the team worked at full speed, so for the future you can expect the same amount of work done. Make it better Their goal was to provide a better tooling for the ...

  This week the Sirius blog post series presents «How to integrate validation rules on a diagram ?». EMF provides a powerful validation system which helps you detect errors in your model. But sometimes you would like to add more rules not already implemented in your metamodel. Sirius is there again! Imagine that we would like to represent the well known Arcade game from the Wreck it Ralph! movie. We define a metamodel to represent the Building present in the game. We also define an isFixed attribute that indicates whether the building is broken or not and so if it needs to be fixed. Semantic validation Then we create a new Sirius specification project and we define a viewpoint with a new diagram named SemanticValidation. A Building mapping is added and provides two different styles according to whether the building is broken or not. We create a model example defining a Game element and a Building, we activate our new viewpoint and create a new SemanticValidation diagram...

Today we swing the Sirius posts series onto another topic : using SVG images in your designers. Maybe you do not know yet but we will have to fight Pixels monsters this summer : Our mission: save the world. Our superpowered team: the SVenGers. BMP The story begins as any superhero blockbuster movie : a bad experiment generates a monster. So our first step in this post is to introduce a pixel monster in the world. We define as usual a metamodel. This time, it represents our SVenGers team : Then we provide a Sirius specification project with a new kind of representation named PixelatedDiagram and a ScalableGirl mapping. As we already saw in a previous post we use the Workspace Image style to modelize our team member. We create a new instance of our metamodel which defines the team with the SVenGers superheroes: And finally, a new diagram is created : Up to there everything is fine. But in our mapping definition we set that the node is resizable: Consequently, the diagra...

  Last time in the Sirius blog post series, you learned how to create an artificial container, today we will see how to create an infinite hierarchy of containers. As an example we will represent the different dream levels featured in Inception : We need to model dream levels and that levels can refer to other sub levels : We develop a first Flat representation to show all the levels at the same stage : A Flat diagram is created and a Level container is defined to represent all the levels defined in the model : Thanks to this representation we see all the different dreams but it is not possible to understand how they are interlinked. Next step we create a SubLevel diagram to represent the first three dream levels : A first container Level represents the reality, then we represent the second dream level thanks to the SubLevel container and finally the third level with another container named SubSubLevel. For each container we retrieve the child level thanks to the le...