lundi 26 octobre 2009

Eclipse Summit : here we come !

I'm polishing and putting the last touches of goodness in my slides for Eclipse Summit Europe. I'm looking forward to a great event as usual, with this warm and fuzzy feeling you have realizing you're part of such a vibrant community.

If you are wondering how "we" - the Acceleo projet became "we" the Eclipse Project, do not miss my talk :

ESE, even more than EclipseCon, is a nice moment to learn more about all the technologies available at Eclipse and to exchange with the teams behind those. I'm going to catch you : " projects I'm particularly interested about ", and ask you questions, even dumb ones ! Please take this chance to do the same about the Eclipse Modeling project !

vendredi 9 octobre 2009

Exploring Eclipse Plugins: beyond Terra Incognita



In software engineering the "Terra Incognita" boundary is never far away from where you're standing. Most software are lacking an "overview" documentation or model and you have to open your path yourself through the code trying to understand what's going on.

That's especially true when you are analyzing a legacy application in some kind of good old language not being considered, these days, as hype as SCALA . COBOl, NSDK are examples among others, reverse engineering become a requirement and at Obeo we are working hard providing tooling so that our customers are able to understand and migrate to other technologies.

That said you don't need a flux capacitor requiring 1.21 gigawatts of electrical power to have this "understanding" issue with technologies. It's still a problem with the application we're building using 2009 ones, let's take the OSGi Bundles for the need of the demonstration.

I already did a draft implementation of a tooling easing the exploration of Eclipse plugin years ago using GMF, and we've got this nifty PDE visualization tools based on ZEST, but I was in the mood of trying again to build a tooling from the following principle:
  • construct and explore step by step
Now that we built this cool technology enabling you to design your own modeling environment, I decided to give it another try.

Here is the result, please note that's a one day work and the underlying runtime is in development (you might catch a few bugs during the demo). Please also note that the demo capture software is not so friendly with the original color, we are rendering the diagram with more than 256 colors ;)

The legend is the following :


The plugins model is captured thanks to PDE APIs, we're going to explore the Eclipse plugins starting from Mylyn, building groups, and seeing what kind of relations those groups have with each others : dependency and/or extension.


So now the next step would be to build the whole Galileo Map step by step, anybody feels like a 21st century Magellan?

Here are a few extras :
EMF Core dependencies


EMF Core extensions
Acceleo.org standalone plugins


Ok, that's Friday and I'm kinda lazy : no text annotations in the demo for now, may be later if I've got thousand questions through the comments..

mardi 29 septembre 2009

Having more control ...

Who never asked for more time to focus on things that matters, like, for instance, gigantic barbecues ?

And then you fulminate against this tool which should help you and which is not,it's just another burden placed on you to provide this documentation nobody will ever maintain or even read. Is that what modeling is about ?

Life as a software user is often harsh, especially as you have, most of the time, no control at all on the software you use. As a developer it's even more difficult as you have an idea on what's going on behind the scene, and not having control is something you just can't handle now that so much open-source products are providing you this power.

If you had control on your tools, if you could adapt it or even easily define it, then you could focus on useful things. Modeling can bring it back to you, not modeling like in UML Modelers, modeling like formalizing your domain model as a way to capture your though or your coding tasks.

A Model doesn't have to be high level, a model doesn't have to provide as much information as your source code, a model is just here to help you answer questions about what you're doing.
If you can't say, for a given model what kind of questions it's helping you to answer, then your model is just not relevant, it's not a model, let's call that boxes with edges.

And now let's take a small example, you wants to define a software using components which are providing services, then you wants to assign these "logical" components to Eclipse plugins, here is a model definition you can come up with :

From an instance of a model you can answer the questions : how is split my application ? what services are provided and required by who ? And how these components are linked to the Eclipse plugins I'm coding ?

From now you can either capture an instance and start working thanks from EMF Dynamic support , or specify a tooling to ease this capture. If a diagram is a good representation for your problem, pick it, if it's not, pick a tabular, tree or even textual representation.

The following demo describe a tooling specification (click on the image! ) at the top, the specification, at the bottom, the tooling which is dynamically adapting itself to the specification.



Modeling itself is useful to organize your though, validate your design or even can help to pick the best trade-off for a given architecture. In a old post I was showing how a modeling tooling having support for viewpoints is powerful in this regard. The next demo is showing you how the developer or analyst, can then leverage the tooling definition (click again !) :

Now you described everything and you're quite happy with the result, why not using this information to help you produce code ? As soon as the modeling environment is linked to the development tasks with code generators, the model is not going to be deprecated, it will be used by the team to get the tedious work done.

Moreover when the environment provides you navigation from your code to the model, then to the code, and support for customizing anything in the generated code, then the tool is no more a burden, but a relief. (yet another demo !)


It's been 3 years now since I arrived in Obeo, and every tool we developed since then has been designed following this motto : "Having more control, not getting in the way and providing value to the developer."

So far I'm quite happy with the results :)




ps : thanks to Jérôme who did the démo

jeudi 10 septembre 2009

The 09/09/09 09:09 0.9.0 Release

Laurent did it not even on purpose, but the latest Acceleo I-build, which is the 0.9 branch, performed well and has this golden qualifier :


So If you're superstitious or a numerology believer, don't miss such a release !

As a sidenote, the Acceleo Team will be at ESE with the talk : "From Acceleo.org to Eclipse.org" And the EEF project, first consumer in Eclipse of the Acceleo Technology will present : "EEF you want sexy properties ..."

If you're interested in the model power, EMF goodness, modeling environments, viewpoints based modeling and/or the Eclipse platform in general, let's meet in Ludwigsburg!

mercredi 5 août 2009

Let's take a step back ...


Lately I had to step back a bit and have a look on what's going on in the software industry. I think most of us did that lately as big players moved their chess pawns and many new technologies seems to have gained some kind of maturity. Many events happened in the last years being evidences the game rules are changing, are all those web apps white or dark magic ?



First we've seen this "Web 2.0 move" and what they call "social software" or whatever, then every single app the "base user" would need had been ported to the web, and now most parts of the "meaningful" data are hosted on private servers all over the world. From the beginning, as an FOSS advocate who thinks that freedom matters more than anything else
I was really standing against those apps.

Moreover from a technical perspective I couldn't say it was making sense: considering your app container is a web browser, I mean,
it's so poor !, that's something which is supposed to be *document centric* and not *interaction centric* you can't really expect more than "drag& drop" from a webapp !
And what's that idea of transforming personal computers to terminals ! It took years to go away from that nonsense and now even the cheapest computer has so much resources ! I'm not even speaking about the "you've got no choice than being connected to the WWW " statement. But now we can say those apps were representatives of a real need for user: another shoot in the software landscape.



But well, things changed quite a lot, the technology grew and Google played a big part in most of those changes, some webapps are now supporting offline mode, user interfaces and interactions got richer, we've got, at least, a pretty good copycat of 90's user interfaces and as nobody really jumped from that, even on the desktop ...



And now I'm facing this big paradox, most of the G-technologies are so cool and well designed I would love using them from a daily perspective, just a quick glance at what Tom is doing or to the E4 effort is enough to make me feel "whoa, our stuffs are so old fashioned, am I
no more a cool kid ?". This path I was considering as doomed have been made brighter by complementary technologies, gears for offline suppport, GWT to be able to maintain this crappy Javascript and provide nice interactions , an many more enhancements.. And though, I keep thinking that most people would prefer using a desktop app if it would manage to tackle the main webapp assets :
- one click, it works and everywhere (which is mainly in the case of web aps : register and you're done)
- no re-install, maintenance should be invisible
- don't care about your data, we're taking care of it

and the
main point, in my opinion being :
- you can share and collaborate with others without even having to care about it !

Those points have been missed by desktop apps, and those points could be done with an approach protecting privacy if the people doing it have no interest in trading information. Eclipse is a platform with a great potential especially concerning the "run everywhere, easy install, update and maintain statement", the "collaboration" aspect is probably the one needing much more love to make our favorite project blossom in the following years.


And now that I washed my mind writting down these opinions I never really had time to organize before, I'll try to focus my activities around those concerns to make Eclipse easier to use, install, and moreover supporting multi-tiers share and collaboration.


Let's jump forward !





vendredi 17 juillet 2009

Feedback from IT companies leveraging Acceleo

The first Eclipse Acceleo Day took place last week and was a pretty nice event., no doubt we'll organize others like that :)

The day started with business feedback about Acceleo deployement and Model Driven approaches in IT units, more especially Cap Gemini, Atos Origin, Orange Labs and Bull. These big IT companies used different approaches to get a higher software quality, quicker, and even more important : easing the maintenance. Each of those approache was valid and was meeting their final goal and Acceleo was a big asset which is really nice to hear when you're part of that team :)
Slides will be available on the event program page.


I really can't summarize all the discussions and presentations in a single post, have a look on Goulwen's report which is way more detailled, but there is one feedback which need to be emphasized : Model Driven Software Development might sound like a big "corporate" expression quite far from the developers actual concerns which is about agility and quality, but it is not.

Using models and leveraging them with code generation techniques is just about that : bringing agility to your development process. With tools like Acceleo which are fully integrated in the Eclipse IDE, the developer has the power to build software systems quicker and better. What we've seen is that most companies are organized in "one transversal team creating the modeling environment and the corresponding generation templates", thats a common organization when a company want's to capitalize over its tooling and templates.



Keep in mind one thing : we are building tools which are making the task of creating of such a modeling environment (modelers, code generators or transformers) so easy, that a developer is able to do it quickly, even just for a single project. You might have a big boost of productivity, quality and consistency on your code just defining a small set of generator templates perfectly tailored to what you want.



So people claiming that Model Driven Development is incompatible with Agile Development are just plain wrong, the tooling supports this kind of development and make it easier, it will just depend on the organization you pick : if your goal is about defining a process for your whole group so that you get quality and consistency over all your projects, then go ahead with the transversal team and keep in mind you'll have to work on your tooling a lot more to handle all the projects use cases. If you just want to build a given software quicker and better, consider defining a tooling in a few days as it will make your life, as a developper, way easier.

vendredi 10 juillet 2009

Eclipse Acceleo Day is going on...

Eclipse Acceleo Day started this morning. The event is collocated with the "Libre Software Meeting" at Nantes (France) . Yes, that's right ,we're part of this huge and lively movement which is free software.

So far the even is going fairly well and many people from convinced users to modeling sceptical ones are attending. Getting feedback from the end user is always valuable.

I'll keep the Eclipse community in touch with what's going on here, thanks again to Freddy who organized the event and to the foundation staff for their help !

mardi 23 juin 2009

Galileo Modeling Package is Here

If you're a friend you can download the Galileo packages. The modeling one is here !


Please notice the great "What's New" page with live content :

Yes, If you're interested in software engineering, If you think "modeling is crap" and you're looking for nice pragmatic tools focused on making things easier, come and join us during the Libre Software Meeting at Nantes the July 10th for the Eclipse Acceleo Day !

mardi 16 juin 2009

Quick glimpse at Galileo Modeling Package

Eclipse Galileo aka 3.5 simultaneous release is coming soon. We now all have this fuzzy feeling when development stops and we stay here a bit dizzy, wondering what we'll do next.

Yet another release, yet another step in the direction of the best IDE, of the best Platform, of the best Modeling tooling or whatever goal you have. The eco-system is so diverse, every new release can't be reviewed as whole, you can only savour "just a bite of this big cake".

Even if I'm quite sensitive to all the good stuffs added in the platform: as a plugin developper these features makes me happy everyday, I'm gonna focus on only *some* features of the modeling package for Galileo...

Each year a few more modeling projects are joining the team for the simultaneous release, you're now getting a full-fledge modeling environment for Galileo.

Let's design stuffs, that's what models are bout, right ? Thanks to EcoreTools, you now have a nice modeler for your domain models. I only want to say one thing: the sexyfication of this modeler is great :) You now have nice gradients, shadows, and many views bringing you stuffs you're used to in the Java tooling : Class hierarchy, Show references and so on..


Definitily worth trying !

If you design your models with a team, you'll be happy to see EMF Compare when you want to merge your changes with those made by your coworkers
Compare graduated and has now the 1.0 stamp ! It's seamlessly integrated with CVS, SVN, GIT and can diff and merge any kind of models.

Speaking about design, xText allows you to design your models using a textual syntax, that's pretty cool and the team worked hard this year, check it out !

Once you design your stuffs, most of the time you want to transform that into something you can use for your development. There are basically two options here : model to model transformation or model to text transformation. Each one having pros and cons depending on your use case.

Eclipse Galileo provides pretty much anything you might want to transform your models, some of them being based on standards :
  • Model To Text (aka code generation) :
JET have been here for quite a long time now providing a steady and stable code generation technology.

XPand and Acceleo joined the release train this year providing template langages with great tooling, debug mode, full featured editors...
  • Model To Model :
QVT Operational and ATL competes in the model to model area.

Work on ATL has been focused on user interface and API, that means ATL is now easier to use from both an end-user point of view and developer point of view.

I looooove the new wizards compared to the old one :)


Acceleo is a complete rewrite from the Acceleo 2.x versions which made our team "Eclipse Award Winners". One of the thing which is cool with this rewrite is that from the beginning we're making sure the core generator is "standalone" and might be used without Eclipse, something we had a hard time to provide a posteriori with Acceleo 2.X . Another common need is the ability to easily launch your generation from your java code, it's most of the time quite tricky when you use your own language.

The Acceleo team came with a nice solution : next to every "main-like" template we generate a Java class which is this template API. Then you can easily launch the generation, you just have to create an instance of this java class and launch it.

Here is a small and dumb template :

And here is the corresponding Java launcher :

Kicking your generation is just a class instantiation and a call to the doGenerate( method ! You have no excuse for not integrating your code generation into your editor.

In a nutshell Galileo bring the best of modeling with pragmatic components, you can't miss that !

vendredi 29 mai 2009

Viewpoints-enabled Modeling Tools

This post follows those showing how it's possible to leverage EMF and JBoss Drools to get an interactive model getting updated considering business rules, and how you can get a set of graphical modelers to ease your design tasks and provide feedback while you're building your system.

Now let's focus on providing "the right feedback at the right time". When you're designing a system, you're trying to reach the following goal : building it nicely and making sure it fits your requirements and contraints. You're always balancing between different concerns, your system simplicity, agility, performances, safety ...

Having a good tooling for that is more than important, and the tooling failed since now : it's always providing many more information or possible actions than what you actually need and not what's your focus right now.

Here comes the viewpoints (IEEE) , viewpoints enabled tooling is able to extends, hide, or provide new representations and actions depending on what you want to consider. As building a system is always a trade-off between multiples criteria, you don't want to be overwhelmed with all the constraints feedback, you just want to see relevant information and be able to do relevant actions. The concept is quite similar to the Eclipse perspectives.

The first demo (a few minutes) provides an overview of the tooling specification model we started in the last post. It's been completed with a few more representations, validation rules, and, more important, re-organized in term of viewpoints.


The following demo (6 minutes) shows the usage of such a tooling, using (again) the simple "Flow" example.



Eclipse is great as a platform and enables you to build great tooling to that your users stay focused on their business issues (which are complex enough already) . That's what we are trying to achieve with this product.

Moreover, Eclipse Modeling is a gem mine driven by enthusiastic people, don't wait and come with us, resistance is futile ;)

mercredi 13 mai 2009

The 20 minute Graphical Modeler based on Eclipse

My last post about the flow model simulation was really missing a demo so that you get the "live" aspect of the model construction. No problem, that's a good occasion to show you a secret product we've been building on top of the Eclipse Modeling projects since a few year now. In my dictator position on this product you can guess I'm quite excited to show you that, nothing public came out about it since now but the first public release is not so far...

Let's stop the teasing and watch the content, here are a few flash demos . If you're just interested in the resulting modeler, go directly to the last one showing the live model design. If you don't understand what's about that flow stuff or if you're wondering how all that load and capacities properties gets updated, have a look on my preceding post.


The first demos are showing the graphical modeler construction. In a few clicks, just defining the concepts you want to display, how you want to display them and how to retrieve them in the semantic model. You get your modeler in a matter of minutes, and you really should not need more than that as it's quite simple.

I really like the "specifying the modeler and using it side by side" feature even if you need a big display for that and here for the demo I have no choice than scrolling.

The next demo is focused on defining "conditional styles" so that the graphical shapes changes depending on the changes in the semantic model (node/edge sizes and colors), in this demo I also specify the fact that a CompositeProcessor reuse the graphical mappings define for the diagram and that I should be able to create a sub diagram on a CompositeProcessor.
The request langage I'm using is Acceleo, but you could also use OCL, I tend to prefer simplicity ;)


And at last, after a bit more tweaking off stage, the usage of this finished dynamic modeler.



So, to be fair, the final modeler is more a 25 minute modeler than 20, but that said, I get a first working modeler a the minute 10 of the first demo.

Be sure that's only a tiny portion of what we've been able to achieve leveraging the Eclipse Modeling components (EMF, GMF, Acceleo, Compare just naming a few...) and the Eclipse Platform : graphic modeler are one thing, but other representation matters and I'm not even speaking about the "full viewpoint support".

Stay tuned for more eye candy ;)

mardi 5 mai 2009

Live Models Using JBoss Rules (Drools) and EMF

Modeling Kata here again ! Models are useful to describe things, systems, knowledge, basically any information you want to organize and formalize will gain in using a solid formalism like Ecore.

Structuring and describing is nice, but then most of the time you need to evaluate your design. You basically have choices here, one of them is using the validation tools so that any "error in your design" is shown to you and so that you can fix it. The drawback of validation is that you can't easily get the big picture of your design quality corresponding to the constraints you defined.

Who can say that this bees invading my garden are organized in a nice or poor way ? That's definitely not a binary information.


Another approach is designing your models with tooling updating or self-constructing other part to gives you information about its quality. Let's take a (quite naive but still interesting ;) ) example :

I defined a formalism for a "flow-like" langage, you can use it to describe DataSources and Processors linked by DataFlows. Processors and DataFlows are capacity bounded, which mean they've got a maximum capacity and under given load will be iddling or over used.

Here is a class diagram displaying the simplest parts of the flow.ecore :
Here I'm mixing both the information I'll describe (a given system with datasources, processors and flows) and the feedback about my design (the flow element usage).

Note that every element here might be activated or not (see the FlowElementStatus enumeration).

Now to define my rules updating each values considering the overall model, I basically have the choice either to implement that in Java, or use a Rules Engine. Implementing in Java might look like a good idea but you'll quickly realise that :
  • adapting the rules to a constraints which are specific for a project will make you redeploy everything
  • you'll write code to browse everywhere in the model and update the values depending on your browsing result, and with big models you'll get poor performances
That said, this exercise is interesting and might be the subject of another kata.

You bet I picked the Rules Engine, so that I can get my hands dirty with those strange beasts you (most of the time) never ever want to meet again after you graduated. I picked JBoss Drools which seemd just nice, powerfull, and based on an implementation of a Rete-like algorithm - which make it fast - and I have to admit I liked their logo is really cool.

EMF and Drools are going along really nicely. Drools considers your Java instances as facts and is then really easy to integrate with EMF. EMF provides the generic notification mechanism which make it really easy to integrate with drools so that drools know that something changed and that he might have some work to do.

Here is the result, let's design a flow related to my work :
Freddy is a datasource which produces lots of information (8). He's inactive right now (see the red icon ;) )

Let's add Laurent which is way more quiet, "Me" which is a processor both being a flow target and a flow source, as I'm providing data to "My Computer". My Capacity is 10, my computer has way more capacity than me.

Let's connect everybody with DataFlows, each of them having a max capacity of 10.
Freddy and Laurent are both connected to Me, and I'm connected to My Computer.

Everybody is inactive, let's activate some part of the system : Me and My Computer.
As long as Freddy and Laurent are not there, everything is fine, my usage is "low".
Activating elements in the editor, everything gets updated "on the fly" and the labels are reflecting the current usage of an element.

Now Laurent is activated. Everything is still fine (you kind a guess the next step, right ? ;) )


Freddy is activated, I'm over stressed (see the red) and even the dataflow from Freddy to me has quite an high usage (orange color).

So now I have different options, I can redesign my system in a way that the capacities are higher (for me and/or the dataflow), or split parts of the Freddy flow and distribute it on other processors. I'll be able to try every solution, activate/desactivate elements, and see if my system is meeting my constraints or not.

Now let's have a look on how I did that...

Here are the rules I'm using, quite straightforward and it's easy to put more rules expressing really complicated constraints.

This language is dedicated to the logic rules definition and is, as a matter of fact, good at it.

Mixing drools and EMF has just been about setting up an adapter on my resource when loading the model, then if something gets updated, EMF tell drools which instance changed, and drools fire the corresponding rules, chaining them if needed.

I'm not the first one doing that, googling a bit you'll find papers.

Quick reminder of what's nice with this approach :
  • not re-inventing the wheel again
  • great expressiveness for your rules
  • great performances even with many many many rules
  • rules are easy to customize and you don't need to change your code to consider new construction rules.
Stay tuned and feel free to provide feedback on a similar or different approach !

vendredi 24 avril 2009

Award Winning Acceleo moving to Eclipse

Thank you from the Acceleo Team (unfortunately not complete here, have a look on the team pages for core and modules) !



Thanks for all the people involved in Acceleo's winning the "Best Open Source Eclipse-Based Developer Tool" price this year. No doubt you'll be quite pleased to hear that "Next-gen Acceleo development is taking place in Eclipse.org ", right there, in the M2T project.

The next-gen Acceleo has many differences with the Acceleo.org one, especially :
  • efficient standalone support right now, that means you can reuse the generation engine even outside of an Eclipse or OSGi context, just put the EMF and OCL jars and you're done.
  • a new statically typed syntax based on the MTL OMG standard
  • aspect-like patterns to extends existing cartridges.
  • automatically generated Java API for your generation module. It's then really easy to leverage a generation cartridge from your own action or wizard.

But we keep the fondamentals that made Acceleo.org a success, especially:
  • Pragmatic vision : let's make it easy for the 95% stuffs everybody does, let's put Java extension for the remaining 5% stuffs not everybody needs.
  • Nifty tooling : debug, completion, show references, open declaration, highlighting, markers, any feature you expect from an Eclipse Editor is there.
  • Community : the Acceleo.org community has been pretty active in providing a full set of "ready to use cartridges" for a lot of technologies (JEE, PHP, C, Python, C#...). No doubt this community will follow the project on Eclipse and expects nice pragmatic generators. EEF is opening the path.

Want's more ? Here are a few demos :

Creating a new project From a Sample


Acceleo Eclipse Tooling

Overview of the Acceleo Syntax

Migrating from the old syntax to the new one


Want's more and more ? Acceleo is part of Galileo and builds are provided.

Do not hesitate to have a try and give feedback on the M2T newsgroup !

mercredi 25 mars 2009

Modeling your EclipseCon

EclipseCon has been going on for a few days now, and I'm quite happy to say this year's event is great, especially concerning the social interactions. I've been coming here in Santa Clara for a few years now and I had the pleasure to meet, in real life, many of the Eclipse commiters and contributors. That's why going back there now also mean seeing friendly people again and having great time with them.

It started with the AC meeting on Sunday, which Martin perfectly handled (as usual). It's really nice, for a newcomer in these councils like me, to see that things are going on, and that people are pushing stuffs to make it real ! So please, do not hesitate to ask the AC !

It continued with the tutorials which really helps newcomers to adopt and understand our technologies. That was the occasion to meet many new people which is kind of a refreshing thing :)

From the Modeling perspective, this years also opens a lot of opportunities, despite the fact that our benevolent dicator is not with us right now, our community is really active and pragmatically tackles real world problems. The modeling BOF was a good example of that, and may be even a bit too much. We have not been able to have a really controversial debate as usual, I guess people keep that kind of stuffs for the numerous e4 events during EclipseCon !

One of the BOF result you'll soon experiment is that more "business cases" of successful usage of the modeling technologies will be advertised. Basically everybody in the BOF had at least one successful customer story to tell and that kind of feedback could be valuable for the community as a whole.

Speaking about pragmatic implementations and success, my talk about EMF Compare went really well, the room was filled with people already using, or interested in using modeling ! The corresponding slides are (at last) here :

unfortunately the demo links have been lost during the slides upload, you can watch the talk demos :
Metamodel agnostic diff/merge supporting multiple ressources
Platform Team API integration (CVS, SVN and GIT)
Graphical modelers integration (draft)
EPatch feature

Extensible diff model export


Among the interesting questions I had at the end one was : "Can EMF Compare is not able to compare a 50Mb model ? I tried and it crashed" - well, that's right, no doubt there is room for optimisation in the generic match engine used by EMF Compare, but comparing two versions of a whole huge model seems quite inappropriate most of the time, that's basically the same thing as if you would like to compare your C: drive with your D: drive, what's the point ?
EMF Compare 0.9 (soon to be 1.0) now supports model fragments, just split your models !
hat said, some of the use case for such a model (and even way bigger) stays valid and that's why I launched the GSOC idea about "comparing huge models" - by huge I mean millions of elements or more. That requires a very different algorithm, and specific handling of the "runtime data" needed to compare the models. Interesting subject indeed !

The good news is that seems like this subject is interesting students, great ! go ahead ! and provide a great application !

Another proof that pragmatism with modeling helps , Acceleo won the "
Best Open Source Eclipse-Based Developer Tool" , I'm really sorry not being able to get my pictures from my camera right now because it contains a proof that girls can't
resist on a kiss from a french guy, just imagine the picture with Jonathan and Lynn ;) . We've got an high standard to keep !


Stay tuned as EclipseCon is not over, I'll come back with even more event reports and "imaginary pictures"



mardi 10 mars 2009

Eclipse Modeling Summer of Code 2009

Yes, summer is coming fast, and if you're a student interested in software development and engineering, Eclipse is a great place for a Summer of Code !

New ideas are still appearing on the wiki page and no doubt you'll get many more in a few weeks. Let me highlight some of the cool subjects you might apply for if you're interested in modeling.

Let's speak about EMF Compare, we tried to focus on cool stuffs as that's what open source is about.


First, the 3D visualization ! Using EMF Compare, the GMF Diagram support and GEF 3D, one can imagine to get a nice "time machine like" visualization of the model differences. One can easily imagine really nice representation using that third dimension, we have to display two (or three) versions of a diagram annotating the diagram elements with graphical hints saying "that's a new element", or "this one has been changed", so 3D can make sense here.

Second : huge models comparison , by huge we mean really huge like millions of elements. EMF Compare uses an heuristic-based algorithm to compare two models, while doing so its keeping processing data in memory (more important the models are, the more memory is used). The subject is two folds : first design and implements a MatchEngine needing less stuffs in memory, then leverage Eclipse technologies like CDO or JCRManagement in order to break the memory bound ! That may seems trivial, but when you need to process a lot of data, many parameters are changing.

Third : improving the "Graphical Compare'" proof of concept initiated by Tobias (flash demo here) .

Many more ideas are available and looks really cool especially in the modeling area, so If you're a student, jump and meet the Eclipse Community !