Tag Archives: pde

Model my PDE!

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.

scr-equinox-1.1

  • 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:
<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>
  • 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:

pde modeling

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 🙂

Fiche de référence OSGi

Equinox & OSGiEn guise d’avant-goût au livre “Equinox and OSGi: The Power Behind Eclipse“, une fiche de référence sur OSGi et son implémentation de référence Equinox a été concoctée par Jeff McAffer et mise à disposition sur le site DZone.

Attention, il faut un compte pour pouvoir télécharger le PDF —et je n’ai pas le droit de le mettre à disposition ici 😉 .

En 6 pages, Jeff fait le tour de tous les concepts de base d’OSGi/Equinox, et répond à des questions que tout développeur de bundles OSGi (et plus généralement de plug-ins Eclipse) s’est un jour posé :

  • Faut-il préférer l’en-tête Import-Package à Require-Bundle pour la gestion des dépendances?
  • Quelle sont les différences entre les services OSGi, les declarative services et les extensions Eclipse? 
  • Comment manipuler ses bundles depuis la console OSGi?
  • etc. 😉

A lire absolument!

OSGi en bref : La directive singleton

En développant vos plug-ins, vous avez peut-être un jour été confronté à une erreur, à première vue obscure, due à une directive singleton soit disant manquante…
En effet, le PDE lève une erreur lorsqu’un plug-in qui n’est pas “singleton” souhaite définir des extensions ou des points d’extension.

Pourquoi, et qu’est-ce au juste que cette directive  ?

Bundle-SymbolicName: com.acme.module.test; singleton:=true

Dans la norme OSGi, il est indiqué que “singleton” (renseigné dans l’entrée de MANIFEST Bundle-SymbolicName) doit être placé à true lorsque l’on souhaite interdire la résolution par le framework de plusieurs versions d’un même bundle.

C’est donc tout à fait logique qu’un plug-in amenant des extensions ou des points d’extension soit impérativement un singleton ; car il serait sans cela très difficile, voire impossible, de gérer les différentes versions résolues au runtime…
Imaginez simplement un plug-in amenant une vue, que l’on pourrait déployer dans deux, trois, … versions différentes au sein du même Eclipse : à quoi devrait-on s’attendre lors de l’affichage du menu “Show View > Other…” ???

Dans le cas où on écrit un plug-in n’amenant ni extension ni point d’extension —un plug-in de librairies, par exemple—, on sera en revanche ravi de pouvoir dire que ce n’est pas un singleton (c’est le comportement par défaut), et ainsi faire coexister différentes versions de nos librairies dans le même Eclipse. C’est d’ailleurs exactement ce qui se passe avec les plug-ins ICU, Ant ou log4j, dont les utilisateurs viennent dépendre en venant préciser le numéro (ou l’intervalle) de version qui les intéresse…

Eclipse 3.4 M7 est là !

Ça y est, Eclipse 3.4 est à nos portes puisque le milestone qui sort aujourd’hui est le 7ème du nom ; ce qui, dans le cycle de développement Eclipse, veut dire que toutes les nouvelles fonctionnalités ont été implémentées (feature complete) !

Les prochaines versions livrées seront des releases candidates, au nombre de quatre d’ici fin juin, et n’apporteront donc que des corrections de bugs.

Voici comme à chaque fois les nouveautés à noter, sachant que, pour une M7, on est plutôt gâtés !

Equinox

  • Les certificats des paquets installés via p2 pourront maintenant être visualisés, un peu de la même manière que vous pouvez vérifier le certificat d’un site auquel vous vous connectez via votre navigateur Internet,
  • L’IHM de la boîte de dialogue Software Updates amenée par p2 est désormais définitive (hé oui, on a dit feature complete, faut suivre un peu…) et devrait même vous permettre d’aller encore plus vite qu’auparavant dans la gestion des mises à jour, notamment grâce au mécanisme de filtre implémenté dans l’arbre listant les Installable Units.

PDE

  • Vous pouvez désormais marquer un point d’extension comme étant internal. Cela n’interdit pas à d’autres plug-ins d’étendre ledit point d’extension, mais ils seront prévenus qu’ils font quelque chose de pas catholique avec un warning ou une erreur (voir sur la capture d’écran),
  • Le tooling autour d’OSGi commence à prendre de plus en plus d’importance, avec notamment l’affichage des services déclarés et consommés par chaque plug-in dans la vue Plug-in Registry.

Platform / SWT

  • Possibilité de sélectionner une ligne en appuyant sur SHIFT et en cliquant sur la règle qui affiche les numéros de lignes dans tout éditeur textuel,
  • Rechercher/Remplacer. Nouveau pattern d’expression régulière \R qui, lors de la recherche, trouve n’importe quel délimiteur Windows, Unix ou Mac (respectivement \r\n, \n et \r), et, lors du remplacement, insère le délimiteur adéquat (i.e. celui configuré par défaut pour le fichier en question, et qui est utilisé quand vous tapez ENTREE dans un éditeur).

JDT

  • Le compilateur Java d’Eclipse (ecj) tire maintenant pleinement parti des machines multi-processeurs et multi-cores. De plus, les builders autres que le builder Java peuvent également bénificier de cette accélération !
  • La JDT supporte désormais les fichiers RAR ajoutés au build path ou au source path,
  • Le formatage de plusieurs fichiers Java à la fois est désormais annulable avec CTRL+Z. Rappelez-vous, auparavant, on avait droit à une jolie boîte de dialogue “Undo is not supported by this operation. Do you want to continue?” !
  • En mode debug, le survol d’une variable affiche les structures (maps, tableaux, …) de la même manière que le fait la vue Variables.

Le New & Noteworthy complet est ici !
Et pour le téléchargement, c’est par !

Eclipse 3.4 M6 – API Freeze !

NoteworthyAvec quelques jours de retard (il semblerait que l’intégration de p2 ait été assez laborieuse…) voici la cuvée M6 d’Eclipse 3.4 !

Comme pour chaque milestone, voici les nouveautés qui ont particulièrement retenu mon attention :

Equinox

Beaucoup de sous-projets qui étaient jusqu’alors en incubation ont été gradés et font donc maintenant partie du projet Equinox “officiel”, et sont ainsi accessibles aux utilisateurs du SDK Eclipse. Parmi ces projets :

  • p2 (prononcer pitou !). Pour faire (très) court : le mécanisme antédiluvien d’installation et de mises à jours de “features” a été totalement refondu. C’est la nouveauté de cette milestone, et je serai amené à en parler plus en détail très prochainement !
  • Equinox Security. L’idée est de faciliter l’intégration de mécanismes de gestion de la sécurité (authentification, autorisation, …) dans Eclipse. Le plan pour la 3.4 comprend les items suivants :
    • intégration de fournisseurs de sécurité Java
    • framework d’authentification utilisateur
    • gestion des certificats utilisateur (gestion de mots de passe, clés, …)
    • support de l’autorisation de code des bundles (à l’installation, au chargement, à l’exécution…)

PDE

  • Le projet incubatoire API Tooling a lui aussi été promu, et est maintenant intégré à Eclipse.
    Le principe de ce projet est de mettre à la portée du développeur un certain nombres d’annotations Java et de processeurs associés afin de faciliter la documentation et la maintenance d’une API. On peut par exemple utiliser une annotation @noreference lorsque l’on veut indiquer qu’une méthode (définie dans une classe abstraite, par exemple) ne doit pas être appelée par les “clients”. A l’heure actuelle, ce genre de contrainte était tant bien que mal explicité dans la javadoc de la méthode (“Clients must not call this method” …), et le moins qu’on puisse dire c’est que ce n’était pas très formel, et encore moins exploitable de manière automatique.
    En outre, API Tooling peut détecter tout un tas d’erreurs auxquelles tout le monde à un jour où l’autre été confronté, comme par exemple la définition d’une méthode dans une interface exportée, qui retourne un type qui lui n’est pas exporté par le bundle ; ou, mieux, détecter la rupture possible de compatibilité lors de l’évolution d’une API (ajouter une méthode à une interface rend caduques toutes les classes concrètes qui n’implémentant pas encore cette méthode…)
  • Nouvel attribut de type “id” dans les schémas de points d’extension. J’en ai déjà parlé ici, et suis toujours aussi enthousiaste vis-à-vis de cette nouvelle feature 🙂 .

Platform / SWT

  • API pour avoir des labels “multicolores” dans les arbres et les tables. Depuis l’avénèment de la 3.4, vous aviez tous remarqué que la vue qui affiche les résultats d’une recherche, par exemple, était désormais beaucoup plus sexy, grâce à l’utilisation de différentes couleurs. Ceux qui avaient essayé d’intégrer cela dans leur propre plug-ins avaient alors pu se rendre compte qu’il n’y avait pour l’instant pas de quoi manipuler simplement ces couleurs depuis la couche JFace. C’est désormais possible ! StyledCellLabelProvider est la classe abstraite à étendre pour avoir le support de cette nouvelle fonctionnalité ; IStyledLabelProvider permettant de venir enrichir un LabelProvider qui auraient déjà une super-classe. A noter que cela ne se résume pas qu’aux couleurs d’avant et d’arrière-plan puisque l’on peut également souligner, encadrer, mettre en gras, … certains tronçons de son label !
  • Partage de projet CVS. Une nouveauté toute bête mais trèèès pratique : on peut maintenant, lors du partage d’un projet CVS, venir simplement choisir le module dans lequel on veut que notre projet vienne se rajouter, et un sous-module du nom de notre projet Eclipse sera automatiquement créé !

JDT

Pour les curieux, le New & Noteworthy complet est ici !

PDE UI guys rock !

Kudos to the Eclipse PDE UI Team (and more specifically to Chris Aniszczyk) for their incredible work on a long-awaited feature in PDE : “type safety” for ID references! 🙂

So, what is it all about ?

screenshot.pngImagine you want to contribute to the org.eclipse.ui.perspectiveExtensions extension point, in order to plug your own views on a given, existing perspective.

Your perspective extension is going to be relative to… a perspective, right?
This perspective is identified by an ID, right?
But what is the actual ID of the perspective you want to extend? And what happens when, even knowing the exact ID of the perspective, you make a spelling mistake? Let me guess… You lose at least one hour of work in the so-called “id hell” 😉

That’s exactly why the PDE Manifest builder (i.e. the compiler of your plugin.xml against extension points schema and workspace/target platform plugins) will now handle a new kind of extension attribute : the ID!

screenshot2.pngWhen you want to add an “idref” attribute into an extension point, you just have to declare the attribute as “identifier”, and you then tell which identifier you want to refer to. And voilà !

The patch has not been committed on HEAD yet, but you can find the patch in the attachments of bug #181515.

Sebz, this new feature is for you 😉

…Welcome in ID heaven!