We've been in some sort of "Stealth mode" since the proposal for Eclipse Sirius got accepted. It did not makes sense to us to communicate on Sirius as long as it's not there, in Eclipse. That said, the summer actually was quite intense, I'll start by a quick status report :Pierre-Charles worked on preparing the move to the Eclipse infrastructure and the Foundation IP Team reviewed the code. We just got the green light from Sharon (kudos to her!) and the code was commited by Stéphane Bonnet (Thales) two weeks ago . The code is now hosted on git.eclipse.org. Continuous integration and gerrit are operationals though builds are not published on Eclipse.org yet.Right now the team is  working on 6 different streams to prepare for upcoming releases, notably Obeo Designer 6.2 and service releases for Obeo Designer 6.1 and 6.0. The team will progressively ramp up on the Eclipse.org infrastructure as our 6 different streams are delivered.We are also taking the opportunity of this big namesp...

We've been in some sort of "Stealth mode" since the proposal for Eclipse Sirius got accepted. It did not makes sense to us to communicate on Sirius as long as it's not there, in Eclipse. That said, the summer actually was quite intense, I'll start by a quick status report :Pierre-Charles worked on preparing the move to the Eclipse infrastructure and the Foundation IP Team reviewed the code. We just got the green light from Sharon (kudos to her!) and the code was commited by Stéphane Bonnet (Thales) two weeks ago . The code is now hosted on git.eclipse.org. Continuous integration and gerrit are operationals though builds are not published on Eclipse.org yet.Right now the team is  working on 6 different streams to prepare for upcoming releases, notably Obeo Designer 6.2 and service releases for Obeo Designer 6.1 and 6.0. The team will progressively ramp up on the Eclipse.org infrastructure as our 6 different streams are delivered.We are also taking the opportunity of this big namesp...

Hi guys! Just realized I did not post about this interview made for InfoQ France. This is a general presentation of Mylyn Intent principles, with useful information to quickly get started (in french) http://www.infoq.com/fr/interviews/interview-alex-lagarde-eclipseconfrance2013 We are currently working on Intent stability and performance, many improvements will be available in the Intent 0.8.1 release (aligned with Eclipse Kepler SR1 in September). In the meantime, you can install Intent nightly builds http://download.eclipse.org/intent/updates/nightly/0.8/N201308121238. And by the way, we submitted an exciting abstract for EclipseCon Europe http://www.eclipsecon.org/europe2013/living-documentation . Melanie will show she used Intent to specify the behavior of UML Designer, and make sure that as soon as she modifies the behavior of the modeler, the specification is correctly updated. Your doc becomes alive, ALIVE! Stay tuned for more news about Intent and Sirius!Lien d'origine...

Today I wanted to talk about one of the components we had to develop for Mylyn Intent: the Markup bridge, which allows to represent any Wikitext-parsable document (written in MediaWiki, Textile, Confluence, TracWiki and TWiki markup) as an EMF model. Notice that this component is completely independant from Intent, and only depends on Wikitext and EMF.   1. Why on earth did we do that? As explained in my previous post, we decided to represent Intent documents as EMF models. An Intent document is nothing more that a set of pure documentation zones (written using a Wikitext syntax) and additional information (links between doc and Java classes, Manifest files…). So to be able to represent an Intent document as a model, we first needed to represent Wikitext content as a model. 2. How does it work?  It is quite simple: we use a Builder Design-Pattern: The MarkupParser (provided by Wikitext) sends signals while parsing a text conform to a Wikitext syntax (e.g. beginSpan(), image(url,...

Hi guys, people often ask me why on earth I use EMF in the Mylyn Intent code. Intent has nothing to do with models (at first sight at least), and yet I use EMF everywhere. I think this question is interesting, and shows that a lot of people still don’t see the awesome benefits brought by the use of EMF & the whole Eclipse Modeling Tools. In this post, I’ll try to briefly list all the benefits and drawbacks of having based Intent on EMF technologies. 1. Storage abstraction: from workspace to database The first benefits is that, by storing the Intent Document as an EMF model (instead of text), I can use any serialization mechanism provided by EMF. The default behavior (provided by the Intent Workspace Support) is to store the Intent Document as an XMI file in an hidden folder of the Intent Project, but we can do much more: using the EMF binary serialization would optimize the disk space for free using the CDO technology to serialize the Intent document allows to store i...