mardi 19 novembre 2013

Eclipse @Devoxx

I'm back from a full week at Devoxx in Antwerpen- Belgium. I was there to present the Sirius project and
Eclipse Modeling at the Eclipse Foundation booth. (by the way, thanks again to the foundation staff !)
It was quite fun to be there with Jelena Alter, Marcel Bruch, Julien Vermillard and Gael Blondelle, we had a good mix of things : Marcel for the Java developpers with Code Recommender, Julien for M2M stuff (which was very hot at Devoxx this year) Jelena and Gael for the Eclipse Foundation itself and me with fancy graphical modelers.

Here are a few random notes :

The conference organization and setup is quite amazing. Wifi worked very well, the venue is a theather complex which means you always get to sit very confortably and the screens are just huge. There was some hacking spaces with peoples hanging there all the time, voting was easy thanks to a bunch of arduino modules installed in each room. Interactions were encouraged with tweets being displayed on every screen in between the sessions, "free to use" whiteboards were positionned in the hallway leading to some wild polls. I liked these small things which are triggering more involvement from the audience.

The content was good or very good in general but could not attend many sessions as I had many things going on at the booth too, but overall I was impressed. It's not perfect though, I had my share of "sexy looking talks" which did end up being very badly presented.

In the end I have seen only a few Java talks, many sessions were related to web dev, cloud, or the now famous "Internet of Things".

I was there as an Eclipse guy and believe me, the Eclipse hoodie is like a secret weapon to get to talk to pretty much any programming rock star. On the other hand there is this trend going on in the Java community about Eclipse being really bad compared to the competition which made me a bit reluctant first, will people attack me there ?

After speaking with many Java developpers during the conference here is my report : most of them are loving Eclipse, as an IDE.
Juno was a lot of pain though and they did not understood why it got released with such poor performances and behavior. They like Eclipse Kepler way better but it's still not exactly on par with what they used to expect, and they expect a lot from Luna, in particular :

  • Performances and responsiveness
  • Quality and reliability, no more ui glitches in the workbench.
  • Java 8 support.
  • Maven integration (Many people have given up on this one starting from Juno...)

In the end the differences between the major IDEs are quite small and we have room for improvements in several points, but users have pain with IntelliJ too.

What about innovative features ? Actually Code Recommender in itself impressed many peoples, and the others could quite easily be impressed with features which have been around for years through specific plugins they did not knew about.

In a way that was kind of a relief for me to see that our work was not completely rejected by the community and that people could say things like: "Eclipse is the best for this, or that" (for instance having support for multiple languages in the same IDE).  Also, several sessions presenting very cool stuff that could not have existed without Eclipse.

But on the other hand it is very hype to reject and bash Eclipse when you want to brag as a speaker.

Of course it was also a great occasion try a few ideas discussed here and there lately. I realized that :

  • "Code Recommender" in itself makes people wanting to use Eclipse again for Java.
  • most of them don't understand what they are downloading from and the whole idea behind the release train. They could not really figure out which "thing" they should download between "Classic", "Java" or "JEE".
  • most did tell me they downloaded "Eclipse" (which means, for instance, the Java package) and were surprised that it was not having the X or Y feature - which actually is part of the release train.  They just have no clue how to discover that.
  • nobody wanted the "uber package" : that would make an un-usable IDE and they don't want feature they don't use to interact with others (and the bloat)
  • the "let's display fake wizards which are provisionning the IDE on demand" was midly received. Most people I talked too want to be sure they won't need to install something more once they prepared their setup. 
  • a "configurator wizard" opening up the first time so that the developpers gets to pick what kind of langage support he wants, which SCM integrations, which bug tracker and so on, kinda excited the crowd. They see that as the perfect way to provision just the Eclipse they want withouth needing to figure out what all these weird feature names are meaning and knowing this is a selection of high quality plugins, all of them being open-source.
  • only a few would be willing to pay for Eclipse, even if it is a special version, and even if it's a very low price. They are used to Eclipse being free and are more willing to click donate than to buy the binary. By the way, they feel like when they click on this donate bouton, they are already helping the development of Eclipse as an IDE.
  • many features of Eclipse, even if they can be installed through the release train and can be usefull for a developper, are not known at all. (the configurator wizard could help here too). This is, again, probably the smallest effort on our side to have the highest impact.
  • several were using Eclipse as a platform, to build applications or tools, and they could not find the same level of flexibility and extensibility in any other platform out there.

This is it for "Eclipse as an IDE". 

Regarding Sirius, I had very good feedback. People were either curious about it or left with the idea of trying it in their own context, which was more than I could expect from such a conference !

mercredi 2 octobre 2013

Eclipse Modeling Package - The Road to Luna

Since the last public survey, my primary focus for the modeling package was :

  • to include Ecore related technologies, or companion technologies with a low UI profile
  • to only include components which are used largely enough to consider them as stable (and not in incubation)
  • to ease the discovery and installation of the other Eclipse Modeling technologies
  • to include what is necessary (Git,Java and plugin development, sdks) to develop your own specific tooling using Eclipse Modeling.
As the package was fairly large at that time one of my primary course of action was to try to keep it slim. Not that I think the size matters that much in the end, but the more we add in the package, the less things works as expected and as testing and validating the package is a one man effort, I had to make choices based on that too.

Several people chimed in lately with other components to include - and as we are starting the Luna cycle I think it is a good time to have another survey and learn about what you expect as an end user.

Please, take a few minutes to answer the following survey, tweet about it, share the link on google plus or whatever so that I can get data to push things forward.

jeudi 19 septembre 2013

Will you be Sirius at EclipseCon Europe ?

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 Continuous integration and gerrit are operationals though builds are not published on 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 infrastructure as our 6 different streams are delivered.

We are also taking the opportunity of this big namespace change to clean-up some long deprecated APIs and to rethink the way Sirius is modularized. See the wiki for more details but in the end, the APIs we are publishing right now will probably move quite a lot until the 1.0 release. We are soon going to draft the plan for the 0.9 and 1.0 releases and officially announce our participation to Eclipse Luna.

In the meantime the Obeo Marketing and Communication team is working on giving the project a visual identity. I can't wait for it!

In a nutshell, everything will be ready for EclipseCon Europe, we'll have RC quality builds of Sirius 0.9 by then, a website, more content on the wiki, published downloads, Obeo and Thales will be actively working on the Eclipse git repository and bugzilla.

You'll get to see the Sirius in action during EclipseCon Europe, we worked on a few cool talks for you :

It will start on Tuesday at 15:00, right after the keynote. Mélanie will  turn Eclipse into an Arduino Programming platform for kids, providing a visual programming environment not unlike Ardublock (you bet, based on Sirius). How can we tweak the Eclipse user experience so that even kids can use it ?

On Wednesday at 14:30, Sirius, Changing the Game of Systems Architecture, a sponsored talk presented by Etienne and Frederic in which you'll get to learn about a collection of Sirius case studies from a space agency to an insurance company and for each of them how Eclipse Modeling - and Sirius - have been effectively combined.

At 16h15 Stéphane Bonnet (Thales) and Pierre-Charles will present Sirius By Example : Build Your Own Diagram, Table and Tree Editors in 20 minutes. This talk will give an overview of the main Sirius features, and show how to use it to create custom tooling around a given technology. You will also learn about the origin and history of Sirius and how it has been deployed in operational and intensive contexts within Thales. It was given at EclipseCon France, the room was packed and we had a very good feedback about it.

Right after this talk, at 17:00, I will present EcoreTools 2.0 : The Making-Of or "How to transform a GMF based modeler to a Sirius based one". You will discover how I used Sirius's features - some of them quite advanced - to re-design the user experience of EcoreTools.

Then the team will gather for a Sirius BOF (to be announced) . You get to ask any question about Sirius and we will be glad to coach you in getting started with the technology.

Last but no least, Obeo will have a booth during the whole conference, feel free to come by to ask questions or even just to have a chat. We are always eager to learn about use cases or experiments.

I'm looking forward to it. If you're interested in modeling and did not register for EclipseCon Europe yet, consider doing it, I guarantee you'll learn a lot !

mardi 19 mars 2013

Introducing Eclipse Sirius

You might have noticed some signs of excitement from us lately, one being the following tweet :

What was sent at 4:45pm? a new project proposal for Eclipse, one which, in my opinion, is a major event.

Let me introduce you to Eclipse Sirius !

Have you ever wanted a nice graphical environment customized for your domain data but been discouraged by the complexity of all the technologies needed to create one? Maybe you compromised and decided to use an existing format or notation, even if it does not completely fit your needs, just to benefit from the associated tools. Fear no more! Instead of adapting your needs to some existing tool, with Sirius the tooling adapts itself to you, as it should be. And you don't even need to learn about the Eclipse Modeling stack, we did it for you.

That said, if you want to tweak something you can always plug your customization in through the underlying frameworks, namely : GMF, GEF, EMF and the Eclipse Platform.

How did it all start ?

It's no vaporware. We started the development of Sirius a few years ago with Thales. We've set-up together a great team to build this technology, known as Doremi at that time.

Thanks to this collaboration, we've reached a very high level of maturity: Sirius is used in many very large projects within Thales and it's been around in Obeo Designer for a few years already. It is also the foundation of several tools you can already find in the Eclipse Marketplace, some of them being installed by more than 2000 users a month.

We are not kidding.

This contribution to Eclipse means a whole new team will become commiters. They have been working on Sirius for years and you already know them as contributors. You will now see those guys from Thales and Obeo co-leading and working in the open.

What about Obeo Designer ?

Sirius is one Obeo Designer's components. Once published via Eclipse the Sirius open source version will be included in Obeo Designer.

Sirius being open-source doesn't change much besides strengthening Obeo Designer by significantly growing the user base of one of its components. This means more diverse usages, more tests "in the wild" and potentially more designers to reuse or extend.

Obeo Designer remains a commercial product : a strong and open platform to build and deploy your modeling environment with well integrated and tested components. It is the perfect companion for professional usage by bringing collaborative modeling and support.

Why ?

First because it is in our DNA, we strive to build great products in the open. And our partners are supporting us on this, especially Thales, since Sirius is the result of many years of a joint and rich collaboration with Obeo.

Secondly to unleash the energies in Eclipse Modeling. There is a lot of interest in this domain,  companies are in dire need of solutions but the cost to fill the gap between what they need and what Eclipse Modeling provides right now is too high. We are reducing this gap with Sirius and this will trigger more usage and more funding for Eclipse Modeling as a whole.

We also want to work with you, fellow commiters and OSS tool providers, in building the best tools ever. We are building a great component, but having a non open-source runtime may slow down its adoption. This last barrier is now gone.

Have some questions ?
I'm sure you have tons of them. Please use the dedicated Eclipse forum.

Want to know more ?

I'll be at EclipseCon Boston next week. At 1:30 pm On Tuesday .

I'll present the project with Stephane Bonnet from Thales in the session :

"Your custom modeling environment definition made easy. At last !"

During this session you'll learn about the project, its goals, its current deployments and you'll see it in action with live demos.

I will also introduce the project during the Modeling Symposium later the same day !

Sirius brings you the ability to quickly define your dedicated editors : diagram, tree, tables, it would be a shame not to show you what you can do with it :


mercredi 13 mars 2013

Learning from the source

I don't know about you, but at Obeo we're preparing for EclipseCon North America. Eclipse Conferences are great, so many things are built on top of Eclipse or within the Eclipse projects. Tooling of course, but also rich applications, runtimes, you can get a clear vision of what's going on in these areas in just a few days being there.  You could think : "all right, but he is an Eclipse commiter, of course Eclipse conferences are interesting to him". Actualy I'm also CTO at Obeo and when Obeo comes at EclipseCon it's not a one man trip. Seven people from Obeo will go this year to Boston, it's not unusual, and for a company like us it's no small investment.
So, with my CTO hat (and not the Eclipse commiter one) let me give you a hint : its worth it !

During a few days your team is getting to learn from the source ! The community is so diverse, they will learn about developping mobile apps, web apps, rich applications, runtimes, but also about product management, tooling, business intelligence, quality, processes. They will learn tips and tricks on using technologies and in our world these tips are making the difference between a successful project and a complete failure. The knowledge you'll get is high quality:  you'll learn either from people using the technology day to day or from people actually building the technology !

Looking back at the few years the company have been around, there is no doubt Eclipse conferences had the most profound impact on how we use technology and how we develop products.

I'll take a few samples from what we are presenting there but make sure you have a look on the program yourself.

EMF Compare 2.0 : Scaling to Millions : performance and scalability related talks are in general giving a lot of insight into a technology. Here Mikaël will describe by which mechanisms Compare is now able to produce diffs from models too huge to even be completely loaded in memory and merge these diffs while keeping the model integrity.

EMF.Edit : the Force Unleashed : how EMF brings a flexible command support, and how you can use it even not how of an Eclipse context in for instance, a JavaFX application.  "This talk is dedicated to EMF rookies that know EMF as a generator of JavaBeans on Steroids and want to know more about steroids "

Documentation Driven Testing : if you think documentation is an important part of your software but you don't want to spend time doing it for nothing.

Buildroot Eclipse Bundle : a powerful IDE for Embedded Linux developers : see how Eclipse tools can help in building your complete embedded Linux system.

Stop Throwing your doc away : Agile Documentation with Mylyn Intent : you might learn there how the tools from Eclipse can save you a lot of time telling you where your documentation is not up to date.

And thats a tiny extract of the conference which has 7 parallel tracks during 3 days +  a full day of 3 hours tutorials.

And I am not even mentioning the discussions, the BOF sessions and the keynotes.

Well, of course you won't be able to send all your developers there. Just make sure to send those who are good at sharing knowledge with the others and you'll see it will impact both your software and your practices.

ps :  better hurry to register

jeudi 31 janvier 2013

On being open and transparent

We always intend to run our Eclipse projects as real open-source projects. Being open, transparent and so on. The Eclipse Development process forces you to do so in some way, the simultaneous release brings a bit more constraints in this regards but in the end, if you want a truly open project you'll need to do more.

Let's take EMF Compare. It quickly jumped into the release train, adopted the Eclipse practices, got used by other components and had a number of major contribution.

We have two main groups of adopters: the first group is comprised of end-users, which mostly have the perception the problem itself of comparing models is quite easy and it should "just works". They tend to report bugs, UI glitches, and sometime even with patches. The second group is researchers, they know the problem is not that easy and having this component enables all kind of experiments on top of models for them. They tend to use compare in contexts we never ever envisionned.

We had several fairly big contributions from the second group (research) among the years and have always been keen in integrating them, getting them on board in the team and in the release process. But the contributors tend to fade away when their research subject change or when they leave the academic world.  The problem with "big" contributions is  : we can't really maintain those over time with just the core team.

We also participated in several google summer of code programs, but so far never really managed to transform students into day to day commiters.

Driven by the first group of user, we rewrote many of the core code of  Compare last year, and now is a good time to get more people aboard.

We acknowledged that conferences, bugzilla, release reviews, and blog post were not enough, and we started a bunch of actions :

Being visible

Includes posting notes on the interweb about progress, new use cases. Giving talks in tech or academic conferences, and having a comprehensive documentation.

With the 2.x stream, we had to go over all of our documentation anyway, the User Guide is now in a better shape.

A build system you can launch@home

Building  Compare is just a matter of  mvn clean package
you can point to a specific target platform (we tend to keep the widest compatibility possible) with

mvn clean package -Pjuno

mvn clean package -Pkepler

launching the tests is just as easy :
mvn clean verify -Pkepler

As you would expect,  the builds are run on the eclipse public server.

The only part of the build which depends on the eclipse infrastructure is the signing and promote process, but those are kept in particular profiles.

Contributor 101

We describe our expectation regarding contribution in the Contributor Guide. Our requirements regarding checkstyle, API tooling, specifications documents are described there.

Setting our expectation can be seen as a new barrier to contribution, but on the other hand our expectations have always been that way and not describing it lead to a misunderstandings : your contribution is valuable, makes no mistake, but most of the time there is way more to do than just dropping a line of code in the bugzilla.

Gerrit looked like a good way to ramp up, a contributor can have feedback from the commiters, but also from the automated build launched on top of his changes.  This looks like a win win so we decided to migrate to gerrit and to setup a build which checks the tests on top of the platforms we are currently supporting. The Eclipse wiki is highly valuable for this, and the webmasters have again demonstrated their support in this process.

We'll see how it goes over time, I'm not 100% buying gerrit itself which can be quite intimidating and I'm looking forward to the list of cons Miles will soon publish ;), but it feels right to have this public and open staging area with constant feedback.

Documentation also is a key ingredient here. Have a look on the Developer Guide, I wouldn't say it's complete because it's not, but you can at least start and have a rough understanding of how Compare works behind the scene.

We're not completely done here, we still have to list "low hanging fruits" - aka Junior Jobs or tasks which can be tackled to discover Compare's internals.


To engage developers - adopters which might turn into contributors and maybe at some point commiters you have to at least support them. Laurent is checking the following channels besides the bugzilla : the Eclipse forums/newsgroup and stackoverflow. We always had a great example of that in the EMF community through Ed's relentless effort on the newsgroups.

But to take part in the development of a project, you also need to know what's going on. We were missing a real channel for this : notifying peoples when we drafted the work we are starting and engaging them in a potential discussion about these evolutions We recently decided to use the emf-dev mailling list for that, you might have seen a few examples lately, the golden rule being : these mails are just a starting point for further discussions into a given bugzilla. We won't turn the mailling-list as a very chatty place, on the other hand with only a dozen of threads for one year which are not related to commiter election or project meta-data I think there is room for more discussions.

I can't say this triggered a lot of reaction so far but I'd love to see other projects doing that on the emf mailling list.


Always set expectations. We used to have a fairly thin project plan only describing themes, we now have a detailled one :

One can see which bugzilla tickets we'll work on during which milestone of a given release.
In the process we cleaned up our bugzilla, closing pending tickets, often with a comment "this is no longer true for 2.x, it just rocks".

Also set expectations on a given issue/bugzilla, we always tend to think : "your problem is a real one, we'll have to tackle it at some point", and let the thing open waiting for the moment we'll get back to it. Sometimes, this moment only come months or years after the original report. Being clear wether we'll  work right away on something you reported is important, and stating the contrary is an occasion for an adopter to get onboard.

As a side note, there are times that we look at a bug, think that "this is a totally stupid mistake" ... but then simply forget about it (we're working on something else, we're not on the good branch to tackle it directly...). Do not hesitate to ping us if we do not answer to trivial bugs (such as in a timely manner.


We already have a fairly good track records of openness with many contributions in the history of the project, we'll see if doing so much more efforts will have an impact and I'll sure get back to you then. 

I can only assure you one thing :  it takes a bit more time, it takes commitment, but it feels good.

mardi 22 janvier 2013

Obeo Designer 6.1.0 - no 4.x platform... yet !

We've been quite buzzy in the last few months at Obeo : building and releasing a brand new product dedicated to EA, celebrating our seventh birhtday, building almost 20 modeling environments based DSLs and/or standards, bringing model comparison far beyond the competition, tackling the issue of software and design documentation with a novel approach in the Mylyn project and step by step getting closer to our perfect development process, our unicorn.

And working on Obeo Designer : we just released 6.1.0 bringing among other things :
 - compatibility with Eclipse 3.8  (and Indigo, and Helios)
 - a ready-to-launch server for live and instant collaboration on models with fine grained locks
 - token/floating licenses,  meaning you can now buy license for, let's say, 30 simultaneous users, no matter who.
 - a better packaging, documentation and examples
 - updated versions of all its OSS components : Acceleo, ATL,  EEF, EMF Compare.

Rougly 160 tasks have been closed for this release not counting the work done on the OSS components, it's quite hard to summarize but you can find a few highlights here.

Why Eclipse 3.8 ?

We worked on bringing the 4.2 compatibility  for the product (and are still working on it) but we got hit by some limitations of the compatibility layer.  It was detected late as the problem came when we decided to rely more on the plaftorm mechanisms to get more extensibility... It's not trivial to fix, we are trying to help the platform team as much as we can to implement this either in the 4.2 or 4.3 stream.

What does that mean ? It means on Eclipse 4.2 you don't get the diagram contextual toolbar, also known as TabBar:

This prevents end users to enable/disable graphical layers or to switch to the "layout mode" (a.k.a. VI for diagrams).

That's quite a big loss for end users, you get used to this ability to apply layers on your diagram, but as I said, we're working on it.

Obeo Designer is an integrated platform to build modeling environment. Using it you can quickly and easily leverage the power of the whole Eclipse Modeling eco-system : EMF, CDO, Xtext, GMF, Acceleo, ATL, Compare.... It's packaged, tested and includes additional components to create richer modeling environments, quicker.

The problem with such a product is - as it's a base for you to build things - getting what you can achieve with it can be hard.  One example (among many on the Eclipse or Obeo Marketplace) of what you can do is the UML Designer.  You can install it from the marketplace, and you can have a look at the sources here. We've already seen 580 installations in the last 5 days, yeah !

Well, ok, But what's really new in your product ?

Many changes are not directly visibles in this version, we streamlined the CDO and collaborative support, worked on performances, and introduced a few nice features. Go have a look on the *new and noteworthy* page. This blog post is already filled with sentences making me sound like a boastful person. Ok. Just a small glimpse...

You can now use a new construction in your diagram definition :  Brackets

Using those you can easily represent intervals in a diagram.  You can use it in a sequence diagram just like here, but also in any other diagram.

HTML Export : publish your model. You can browse through an example here.

The complete new and noteworthy (with more pics !) is available here.