I’ve just uploaded the slides of the two talks I gave at Eclipse Summit Europe last week on SlideShare.
Feel free to contact me if you have questions!

I enjoyed the event a lot (cool talks, cool food, cool people), and I already can’t wait for EclipseCon 2010!

There is a generally not-known feature in the Eclipse Help which allows to configure the scope of searches.

By default, whenever you perform a query, the search scope is restricted to your local help repository (i.e. Javadocs, API references, user guides contributed by plug-ins).
However, it is possible to add new “search engines” to this scope. For example, even if you don’t have (and I hope you don’t), every Galileo plug-in in your environement, you may want to search information in the whole Galileo help without leaving your workbench. This is as simple as:

• Opening the search UI using “Help > Search” menu
• From the query form, opening the “advanced settings” of your search scope
• Adding a new search engine. Select the “Info Center” type, and use the following URL : http://help.eclipse.org/galileo.

Similarly, you can use any website allowing to perform queries through URL parameters (e.g. Google) as an Eclipse Help search engine.
That’s exactly what we are going to do in order to allow search on Eclipse Community Forums, the new & sexy Web UI on top of Eclipse newsgroups.

This time, you are going to add  a new “Web Search” search engine,

and you will use the following URL pattern: http://www.eclipse.org/forums/index.php?SQ=0&t=search&srch={expression}&btn_submit=Search&field=subject

And voila! Starting from now, you’ll have search results coming from the online Galileo info center and from the Eclipse Community Forums

I’ve been working for quite a while on finding solutions to the problems we are having in PDE as soon as we need to add support for new OSGi headers, to create new editors for cheatsheet files, p2 categories, etc.

Declarative Services tooling is a good illustration of all these problems. As part of the Google Summer of Code 2008, Rafael Oliveira worked on the creation of some cool tooling to help people wanting to use OSGi Declarative Services. This tooling is great, and available in Eclipse Galileo as many of you may know but, unfortunately, it introduces a lot of boilerplate code (Java model of what a DS component is, Java model of what the textual representation of a DS component is, JFace label and content providers, etc.)

Indeed, since day 1 of PDE, despite the fact there is a sort of generic framework behind PDE (undo/redo support for operations done both programmatically or through the UI/text editors, compiler to check models consistency and create markers, outline, etc.), it is, and always has been kind of a pain to “instantiate” this framework for each new usecase.

People familiar with EMF, and modeling technologies in general, are probably thinking right now that the framework behind PDE should probably model-based, and of course they are right! That’s exactly the purpose of the ongoing “model my PDE” work being done in the PDE incubator. In this post, I will quickly explain what is currently available in HEAD of the project, further explanations may come in later posts (by the way, feel free to ask precisions on specific topics!).

Generic Forms editor

The org.eclipse.pde.emfforms bundle proposes some abstractions of what is generally needed to create a Forms editor for any kind of EObject. Thanks to EMF.Edit and Databinding framework, it makes it really simple –sometimes you won’t even need to write a single line of code– to create your UI and bind it to the model, display the errors on your model, show an outline, and stuff.

Since the project is still incubating, there is of course no clear API of this bundle at the moment, but if you need to quickly hack a model editor, you should probably have a look at it, and at the “exemplary” implementation which has been done for the “next-gen” DS Component editor.

A non-exhaustive list of the feature provided by this framework (coupled to the features of EMF/EMF.Edit/Databinding and Forms) would be:

• full undo/redo support
• full copy/paste support (both locally to the editor, and from an editor instance to another),
• automatic refresh of the editor if the model is changed on disk,
• model live-validation; displaying error(s) in front of the “guilty” controls, in the forms header, and on the nodes of the elements displayed in Master/Details blocks,
• full drag&drop support in Master/Details blocks’ viewers,
• generic Outline view,
• generic Properties view,
• …

Extensibility

There are many OSGi vendors who work on their own implementation of the standard, and they obviously need tooling for these specificities. In an ideal world, they should be able to extend vanilla PDE instead of reinventing the wheel. We, at PDE, expose some APIs for people to do that (SpringSource Tool Suite proposes tooling for SpringDM, and it is built on top of PDE), but there are many things that are still internal. Our models, our editors, our compilers, are not really designed to be extensible. A model-based approach is the right solution to this lack of extensibility:

• An EMF model is very easily extensible. In order to extend the “Declarative Services” model, create you own, let’s say scr-equinox.ecore, referencing just take the scr.core model. You can now have an EquinoxComponent, extending the standard Component, and bringing some nice Equinox-specific additions. When you will generate the corresponding Java code, you’ll end up with a model which will be 100% editable in the “legacy” Component editor.

• It is very easy to add new validation rules, either enhancing the EValidator generated by EMF, or, way better, using the EMF Validation framework which allows to contribute new rules in a declarative fashion. Not only it allows anybody to “plug” additional rules on top of an existing model, but it also avoids to clutter the model API with dependencies needed only for validation purposes. Indeed, to perform a meaningful validation of a Declarative Services component, you have to query JDT and PDE to check method signatures, visibility of referenced services, etc. For people interested in how an EMF Validation constraint extension, here is an example taken from the incubator code:

[code language="xml"]
<extension point="org.eclipse.emf.validation.constraintProviders">
<category
id="org.eclipse.pde.ds.builder.validation"
mandatory="true"
name="Declarative Services Validation">
</category>
<constraintProvider cache="true">
<package
namespaceUri="http://www.osgi.org/xmlns/scr/v1.1.0">
</package>
<constraints
categories="org.eclipse.pde.ds.builder.validation">
<constraint
class="o.[...].ComponentMethodsAreValidAndAccessible"
id="o.[...].constraintComponentMethodsAreValidAndAccessible"
lang="Java"
mode="Live"
name="Components methods validation"
severity="ERROR"
statusCode="2">
<message>
Method {0}: {1}
</message>
<target class="Component">
<event name="Set">
<feature name="activate">
</feature>
</event>
<!-- ... -->
</target>
</constraint>
</constraints>
</constraintProvider>
</extension>
[/code]

• EMF allows to version models, and has solutions to ensure compatibility between an N-1 and an N model instance. This way, we could probably be a bit less shy when it comes to updating old APIs. Tooling would be written to handle models in version N, but APIs for N-1, N-2, etc. would still be available, and mappers to convert from N-X to N would be too.

Model-aware builder

In order to report errors to the end-user, the editor performs live validation (thus the nice Forms decorators in the screencast below), but there is also a specific builder (once again, designed to be extensible) listening for model changes, and calling EMF Validation behind the scene to check the consistency and create resource markers for every encountered problem.

Screencast

A screencast being IMHO worth a thousand words, here is a live demo of the DS Editor:

If you want to play with this  ”experimental” tool, you can install in your SDK the experimental feature served by build.eclipse.org and corresponding to the result of continuous integration of the HEAD of the project, thanks to Hudson and Athena!

I guess the next important step is now to find an elegant way to propose a Source tab which, as you may have noticed, is almost the only feature being present in the Galileo editor and not in this prototype. Another important step will also be to write the Xtext grammar of an OSGi Manifest, and leverage this “EMF-Forms” framework to propose a cool and extensible editor on top of a Manifest

OSGI R4.2 (thus Equinox 3.5) comes (well, will come, since the spec. is not final yet) with a new simple and handy utility: the org.osgi.framework.FrameworkUtil.getBundle(Class) static method, which allows to retrieve the bundle a given class belongs to.

More specifically, this method will give you the bundle who loaded the given class, or null if the class has not been loaded by the OSGi framework (e.g. if it is a class belonging to the boot classpath…).

Thus, whenever you want to access information such as the version of a bundle, its headers,  etc. without having to query its Activator (perhaps you don’t even have an Activator for this bundle…), you know what you’ve got to use! Of course, whoever says Bundle, means BundleContext, and this handy helper is also very convenient to easily publish/consume OSGi services on behalf of the bundle…

After about 3 years of activity in the Eclipse community, and about 2 years of –not always…– regular blogging in French, I’m finally ready to join Planet Eclipse and start sharing with the community!

I’m interested in many topics, thus expect posts about PDE, OSGi, Modeling (EMF, xText, …), Continuous Integration, e4 , etc. etc.

See you soon and, by the way, you can also follow me on twitter!

PS: kudos to the author of the excellent  qTranslate Wordpress “multilingual” plug-in, which will hopefully allow me to keep my beloved french readers!

I just found this useful link which gathers ALL the Eclipse Ganymede icons, in one and easy to browse place. It also provides  OpenOffice icons (needless to say they are way less cool! ).

Also, for everyone looking for a way to automatically retrieve all these icons, the following script does a huge par of the job since it automatically fetches the icons from the most icon prolific Eclipse projects directly from the eclipse.org CVS:

[bash] #!/bin/sh
CVSROOT=:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse
export CVSROOT
mkdir -p eclipse
cd eclipse
cvs -q co org.eclipse.debug.ui/icons
cvs -q co org.eclipse.pde.ui/icons
cvs -q co org.eclipse.jdt.ui/icons
cvs -q co org.eclipse.vcm.ui/icons
cvs -q co org.eclipse.team.ui/icons
cvs -q co org.eclipse.ant.ui/icons
cvs -q co org.eclipse.help.ui/icons
cvs -q co org.eclipse.ui/icons
cvs -q co org.eclipse.ui.views/icons
cvs -q co org.eclipse.ui.console/icons
cd ..
rm -f ~/public_html/eclipse-icons.zip
find eclipse -name &quot;*.gif&quot; -print | zip ~/public_html/eclipse-icons.zip -@ [/bash]

At last, one of my favorite generalist icons directory is probably http://www.iconlet.com. It will let you search for an icon by keyword, of course, but will also tell you whether the icon is free or not, and under which license it is available if need be…

La quatrième édition d’EclipseTime se tiendra les 23 et 24 juin 2009 à Toulouse.

Cette année, vous aurez en quelque sorte droit à trois évènements en un puisque la conférence se voit divisée en deux journées (au lieu d’une seule les années précédentes), et que la soirée du 23 juin sera l’occasion de se réunir autour du Galileo DemoCamp français.

• La journée de conférences sera l’occasion pour les participants d’être informés des dernières tendances : implémentation de certains composants, applications développées pour des clients… Elle se tiendra à la Cité de l’Espace et sera animée par des acteurs majeurs du monde Eclipse : membres de la fondation Eclipse, éditeurs de logiciels, industriels utilisateurs d’applications basées sur Eclipse.
• Le DemoCamp sera, comme son nom l’indique, orienté… démos (et bières !). L’objectif sera d’une part de fêter la sortie de Galileo (Eclipse 3.5), mais aussi et surtout de présenter les différents usages qui sont faits des technologies Eclipse.
  Inscrivez-vous dès maintenant si vous avez l’intention de venir (et, encore mieux, de présenter un sujet !). On me glisse dans l’oreillette qu’il sera par exemple montré comment Eclipse peut servir à programmer une brique “Lego Mindstorms”, ou comment Eclipse RCP peut être mis en oeuvre pour proposer des interfaces conviviales pour le diagnostic automobile ! Ce DemoCamp se tiendra dans la soirée du 23 juin, à la Cité de l’Espace.
• La session du 24 juin se veut un peu plus technique, et sera découpée en deux demi-journées de formation, permettant aux participants d’aborder le développement orienté composants grâce à OSGi et Equinox, les technologies clients riches sur le marché (Flex, GWT, RAP, …),  le futur Eclipse 4, la réalisation d’IDE à destination du monde de l’embarqué, la mise en oeuvre d’un serveur d’intégration continue d’applications Eclipse RCP avec Hudson, etc.

Pour plus d’informations, et pour vous inscrire, ça se passe ici !

J’espère bien avoir l’occasion de rencontrer certains lecteurs de ce blog lors de l’évènement…

Histoire de vous faire patienter le temps que je trouve un petit moment pour blogger, et si vous cherchez un morceau qui donne la patate, écoutez donc ça ! Au casque, et à fond, de préférence !

 

NB: si le player flash ne s’affiche pas sur votre aggrégateur RSS favori, ouvrez ce post dans votre navigateur !

A noter dans vos agendas !

Le 19 mars, à 16h30, je co-animerai avec Vincent Ducrohet de la société Ingres, un webinar destiné à présenter Eclipse (tant l’atelier de développement que la plateforme), le SGBD Open Source Ingres, et les utilisations qui peuvent être faites de ces deux technologies.

Un cas d’utilisation concret d’Eclipse pour la réalisation d’une application métier (plateforme d’analyse et visualisation de données d’observations satellite) sera également exposé sous forme d’une démonstration.

C’est gratuit, et les inscriptions se passent ici !

La première version, déjà prometteuse, d’Eclipse 4 a été livrée hier.

Au programme, une démo mettant en œuvre les grands principes retenus dans le cadre de cette refonte architecturale qu’est e4, à savoir :

• Le “workbench” de cette démo modélisé de A à Z : les vues, les menus, les commandes attachées aux entrée de ces menus, etc. sont des éléments d’un même modèle, et leur représentation graphique est automatiquement synchronisée avec leur représentation en mémoire (mais pas encore en utilisant l’API de Databinding..!).
  Ainsi, persister l’état de l’application entre deux exécutions devient trivial : il suffit de recharger le modèle que l’on a pris soin de sérialiser lors de l’arrêt de l’application !
• Le styling de l’IHM en utilisant des CSS est supporté, et c’est assez impressionant à voir fonctionner !

---

Un travail particulièrement intéressant a été réalisé au niveau de la couche de gestion des ressources (au sens IResource) Eclipse.

En effet, cela fait plusieurs années que le modèle existant a commencé à montrer ses limites : impossibilité d’imbriquer des projets les uns dans les autres, mauvaise gestion des liens symboliques, etc. Il est ainsi désormais possible, par exemple, de créer des “groupes” logiques de ressources, afin de gérer des topologies de projets particulièrement complexes, indépendamment de leur structuration physique.

---

Enfin, le portage de SWT vers le Web a continué —un premier prototype prometteur avait déjà été montré il y a quasiment un an, lors de l’EclipseCon’08—. Le compilateur Java→ActionScript a été perfectionné, et il est désormais possible de poser des points d’arrêts dans le code Java ayant servi à produire… une animation Flash!

---

Pour un “New & Noteworthy” plus complet, ça se passe ici.

N’oubliez pas non plus d’aller faire un tour sur la page du wiki qui commence à être assez fournie !