EclipseCon Europe 2013 Day 2: Wonderland

Lesson 1: It will fail, keep it simple. Avoid using many technologies you don’t fully master and keep your architecture as simple as possible.

Lesson 2 Choose your technology stack wisely to use technologies that are mature and wildly used by others:

- Does it meet your requirements?

- How mature is the product?

- Is the community active?

- How robust is it to failure?

- Is the cost justified?

Lesson 3: have fun (otherwise you’ll just jump out of the window)

Vert.x (Norman Maurer - Redhat)

Vert.x is:

- an asynchronous platform by nature

- with general prupose

- Polyglot (you can write your app in different langages such as java, javascript, groovy, ruby, python, scala, closure and php)

- flexible

- Supported protocols: tcp, udp, http, https, websocket, sockjs…

It’s based on Netty. You can directly use netty for simple tasks.

Vertx is based on a thread-model: everything is executed in one single event-loop.  Any non-core feature is defined in a module. You can create your own modules and register to the module registry so that others can re-use them. A test framework is provided.

Here is a simple example allowing  read asynchronously in a queue:

public class Server extends Verticle { public void start() { Vert.eventbus().registerhandler("newfeed",new Handler<HttpServerRequest>() { public void handle(HttpServerRequest req) { System.out.println("hello"). } }).listen(8080); }); }

Simple and easy to read. The first milestone inside eclipse has just be released. Definetelly good stuff, I’ll give it a try home.

Markus shared his experience as the lead of the EPP (Eclipse Packaging Project) through the 8 last releases of Eclipse.

Eclipse has gone a long way since the Galileo release (10 projects) to the Kepler release (70 projects). As I already handle the participation of Mylyn Intent (and now Sirius) inside the Eclipse Release Train, I did not learn much here, but I hope that newcommers were interested in seing behind the scene of the Eclipse releases.

EMF ‘n’ Compare: Rescue Rangers (Mikael Barbero)

Mikael took us to a journey in Model comparaisons, showing how can EMFCompare compare, detect conflicts and merge your models.Based on day-to-day use cases, the talk was composed of 3 demos:

1. Comparaison of 2 ant files. We discovered:- how can EMF Compare be automatically plugged to detect differences in XML files in a nice graphical way, instead of having to handle text comparaisons. Everything is integrated in the Eclipse Team Provider UI.- With the appropriate EMF bridge allowing us to raise the level of abstraction (and define concepts like targets, imports…)., the differences are way easier to understand as they use semantic concepts.

2. Detect binary compatibility breaks in our Java code. It would be great to have a tool allowing to compare 2 snapshot of a java code and detect only API breaks. With the appriorate EMF Bridge allowing to represent java projects as models, EMF Compare allows us to provide custom filters through extension points. Here we use a filter that only shows all the changes that actually break the API. I did like that Mikael did not just show an end-user demo, but actually taught us how to implement such filters through EMF Compare API.

3. Incremental transformationWe often define transformations on our models (for instance to transform our business model in a Database-oriented model).Mikael showed us how can we use EMFCompare API to define incremental transformations so that if you convert a business model B1 into a database model DB1, if you modify B1 you don’t have to relaunch all the comparaison but smartly transform only the elements that have not been created in DB1. Smart, efficient, and a good way to show how can we use EMFCompare API in standalone programs.But we still have a lot of corner cases (rename table keys when renamming the table…). Moreover, the database model may not be the direct result of a transformation (if users directly edit this database model).That is when conflict comparaison comes into play.

Mikael concluded by showing another example of customization that we can bring to EMFCompare (such as filters): the graphical comparaison.One of the EMFCompare bridges provide new graphical viewers to see the changes you made on Papyrus diagrams directly on the diagram viewers and not from a tree view. The audience was impressed :) Very interesting Q&A afterward, to sum up it was a great talk.

Statisfy your Requirements - Before your even know you have them (Eike Stepper) Eike is known to make great talks. It was the case that time too :)After having created a Metamodel according to a fake customer needs, Eike listed 10 reasons for which we were not quite ready to deliver, and for which CDO provides answers (I regrouped some of them):1. Persistence: CDO allows to store your models inside a database (of course the physical back-end technology is up to you: PostgreSQL, MySQL, DB4O, MongoDB…). CDO is compatible with several protocols so that your application can “talk” with the CDO Server (tcp, http).2. Transactions: CDO makes sure that all your model modifications occur in ACID transactions. If all your changes are accepted then they can be committed, otherwise you cannot commit a partial and invalid set of modifications.3. Collaboration: CDO provides a real-time notifications mechanism, so that when some user saves changes he made on a model element, all the other clients manipulating that element can be notified & updated in real-time. Of course there is a conflict resolution mechanism.4. Scalability: CDO provides Data Transfert Objects allowign to get rid of the strong references between model elements. This allows to garbage collect EMF objects and hence handle big models. Eike demonstrated this with a nice graph showing the objects loaded in memory, nice and clear.5. Thread safety: EMF is not thread-safe, which can be annoying if you want to do parrallel processes. CDO solves this by allowing you to open a transaction for each thread, which is cheap as all the Data Transfert Objects are shared by all transactions if identical.6. Auditing: CDO provides API allowing you to open “Audit Views”, i.e. a read-only vision of your model as it was at a certain date/commit. Eike made a demo with a slider allowing to go back in time and see the model state, Greater gods!7. Role-based security: I’ll not enter in details here as I coverred this topic yesterday.8. Fault Tolerance/Offline availability: if your connection with the server fails, CDO provides an offline mode support, allowing you to continue working, and commit the changes whenever the master Server is available again.Interesting Q&A, that allowed us to talk about the Query mechanism (to quickly query your whole database in OCL, SQL or your owns Query handlers).

I’m damn proud of being a commiter on this awesome projects, and hope that I’ll help make it even better in the future :)

Sirius by Example (Stephane Bonnet, Pierre-Charles David, me)

The talk went well, I invite you to read the slides and visit Sirius website if you want more news about this new awesome eclipse project :)

I’m posting right now because I’ll be busy at the Sirius BoF tonight at 19:00, attend if you want the sirius commiters to help you defining your own graphical modelers according to your own needs :)

Last post tomorrow, have a good evening !