This year, we will have a full day event, with a particular focus on two topics for which Eclipse is an ecosystem of choice: embedded world, and Machine-to-Machine (M2M).

You should start thinking submitting your talk if you have interesting thoughts to share about:

• Embedded & Modeling for embedded. Modeling technologies have a proven track record in terms of embedded and critical software development. Coupled with other tools and frameworks (ALM, requirements management, code analysis, …), they turn out to change the way software is being developed in the industry, and how it is being supported (usually for years, in e.g. the aircraft industry).
• M2M & Internet of Things. According to analysts, there will literally be tens of billions of connected objects by the end of 2020! This proves to be a challenge in terms of new software engineering needs, of scalibility (Cloud computing and SaaS anyone? ), of management of these huge fleets of “objects” on the field… There are also many new use cases and business models around M2M and IoT that can, and will, benefit from Open Source ecosystems.

If you’d like to share an industrial use case, talk about a project you are working on, or anything related to these topics, you should submit your abstract by Apr. 15, 2012.

More information on the wiki page of the event…  and I am now looking forward to your proposals!

Photo credit: http://www.flickr.com/photos/benurs/5162576672

In order to facilitate the installation of Koneki Lua Development Tools for people not very familiar with the Eclipse SDK (nobody’s perfect, eh?), we are delivering an all-in-one package, that is ready to use.
It is already configured to download updates from the Koneki update site, so you should always benefit from latest features and bug fixes.

If you are interested in Lua development, go check it out now (and enjoy the nice splash screen)!

In this post, I am going to tell you a bit more about the Machine-to-Machine contest that Sierra Wireless has set up for you, in collaboration with freedroidz.

We have built a network of Arduino+Xbee routers that collect data out of sensors (temperature, ambient light, …) and a Lego Mindstorms, and send it to a NoSQL database (MongoDB, actually). Data is consolidated using MapReduce jobs (remember this EclipseCon US 2011 keynote?), and we want you to use all this information to build something innovative and interactive: smartphone application, augmented reality, cool data visualization… Unleash your creativity!
We also think that there are a few Eclipse technologies that you can bring into play to create something even cooler: BIRT charts, Nebula widgets, ECF XMPP provider to post notifications via Instant Messaging, …

The winner will get an iPad2 !

Simulated data is available if you want to start working on your application already. We will drop all the fake data just before the conference starts, and you will then have access to real, live data instead.
Also, keep looking at the contest documentation page to get the most up-to-date information. In particular, we are still polishing a few things regarding SMS interactions, and an RFID scanner that should allow you to come up with applications even more close to real-life use cases. Stay tuned!

For the record, here is how my desk looks like just now… My colleagues would certainly say it is just a little bit messier than usual, but…

Oh, and for all of you interested in geeky electronics stuff, Arduino, and Open Source Hardware, just don’t miss David Cuartielles keynote on Wednesday! But that’s a keynote, so you will be there anyway, right?

You will end up with clickable links for every “bug XXXXXX” encountered in a commit message.
Enjoy!

// ==UserScript==
// @name          git.eclipse.org bug reference detector
// @version       0.1.0
// @licence       EPL v1.0 - http://www.eclipse.org/legal/epl-v10.html
// @namespace     http://www.github.com/kartben
// @description   Make references to Eclipse bugs clickable in git.eclipse.org Web UI
// @include       http://git.eclipse.org/*
// ==/UserScript==

var nodes = document.evaluate(
    "//div[@class='commit-subject'] | //div[@class='commit-msg'] | //a",
    document,
    null,
    XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,
    null);
    
if (!nodes) return;

for (var i = 0; i < nodes.snapshotLength; i++) {
    node = nodes.snapshotItem(i);
    node.innerHTML = node.innerHTML.replace( /.*(bug ([0-9]+))/ig,
        " <a style=\"border: dotted 1px #DAA520; background: #FAFAD2; font-size: inherit;\" " +
        "    href=\"https://bugs.eclipse.org/bugs/show_bug.cgi?id=$2\">$1</a>");
}

I have been spending the last few months working on the definition of what would be the requirement of an Open Source M2M development environment, which has led to the Koneki project proposal. You may have not seen the proposal, so let me use this blog post to explain the purpose of Koneki with more details than in the proposal.

M2M you said?

Yup, M2M. I apologize to Modeling Gurus, but I do not really mean “Model-to-Model”, but rather “Machine-to-Machine“. That is to say, the technologies that allow both wireless and wired systems to communicate with other devices of the same ability.

Let me take the example of a company who sells a home automation solution. This company wants to provide the end-user with a turnkey packaging including a communicating box acting as a gateway between the peripherals (thermostats, light dimmers, alarm system, …) deployed in the house, and a server in charge of centralizing the collected data. The server will then allow both the house owner to remotely monitor is house (e.g. use an iPhone application to turn the heat down), and the solution vendor to manage its fleet in centralized manner (deploy firmware upgrades, collect usage statistics, etc.).

Tooling for M2M development

While it is fairly reasonable to say that half of the time needed to develop an M2M solution is spent solving problems related to the embedded nature of such a development, there are still a few areas that are not covered by nowadays embedded development

Protocols support

M2M solutions usually involve the use of two different kinds of protocols, both of which need to be supported by an M2M-oriented IDE.

1. Embedded protocols – These are the protocols allowing an M2M module to communicate with the assets it is connected to. In the Home Automation use case, that would be the dimmers, the temperature sensors, and so on, and the protocol would likely be X10. For other use cases, we would have Modbus, Zigbee, or virtually any kind of proprietary communication protocol over Ethernet, RS-232, or whatever.
   Supporting these protocols in Eclipse consist in giving developers the ability to interact with the assets independently of their protocols: configure them, access values, send commands, etc. It is also interesting to provide a protocol analyzer (a la Wireshark) allowing to get a human-readable “dump” of all the frames exchanged by the M2M module and its assets.
2. Client/server protocols – These are the protocols allowing a box to communicate with an M2M Server. The M2M server is in charge of centralizing data (temperature, …) and events (fire alarm, …) sent by all the devices paired with it, as well as to send commands (dim the light, …) to these devices. The M2M server usually exposes Web Services APIs to allow system integrators or end-users to manipulate the data to build their own UIs (web sites, mobile phone applications, …).
   There are many M2M use cases where the communication between the box and the server is made using GPRS or 3G connection (Home Automation might not be one of these use cases, because the Internet connectivity is likely provided by an ADSL box…). For these use cases – where we’re speaking of thousand of billboards, solar panels, power meters, … – it is very important to use a dedicated protocol which optimizes the bandwidth usage. Koneki will provide the developer with a way to easily “decode” binary frames into a human-readable form, relying on an extensible mechanism allowing to plug-in support for any protocol.
   Since mobile communication costs tend to be quite expensive,  we want to give the developer more visibility on the bandwidth consumption of its application. For example, will it use more bytes to send a temperature value every 5 minute, or instead send 12 acquired values every 1 hour (possibly benefiting from a compression algorithm).

Component model

In order to enhance software reuse across different M2M applications, Koneki will expose a data/event-driven component model allowing to isolate correctly every functionality of the system. The development environment will use the component model to provide the developer with ways to validate the consistency of its application, to generate its documentation, or even use a visual programming approach to design components graphically (a la Google App Inventor)

Simulation

M2M servers usually are hosted solutions (SaaS or PaaS), making it a bit difficult to diagnose communication problems of an M2M embedded application. Koneki will provide an M2M server simulator to give the developer a better understanding of how his M2M box is interacting with the server, how it deals with timeouts, communication errors, etc.

Lua support

Many M2M modules are programmable using the Lua language (very lightweight scripting language). We not only want to improve the support of Lua itself in Eclipse (another Eclipse project may be created as soon as this tooling becomes mature enough), but also improve the integration of vendor-specific stuff such as: packaging of Lua libraries, communication with remote applications using LuaRPC, etc.

Contribution opportunities

If you’ve gone through the Koneki proposal, you’ve seen that Sierra Wireless’ initial seed will be largely Linux oriented, since this is the OS that Sierra modules are running. However, there are many other M2M modules out there, some of them offering a JVM with an OSGi runtime, other are running dedicated RTOS (e.g. Nucleus) exposing C or C++ APIs, etc. And we want Koneki to seamlessly support all theses different flavors of M2M environments.
Kai Kreuzer from openHAB (a very-cool OSGi-based runtime for Home Automation, with Eclipse tooling easing the configuration of the system) has already expressed interest in the project, and we are also looking forward to work with the Itemis guys behind Yakindu (a modeling environment for embedded systems) to come up with a common component model for M2M systems.

Koneki project is in its proposal phase, so please let us know (best way to do so is to use the dedicated Eclipse Forums thread) if you have any interest in it, … the more the merrier!

Learn more

I will be at EclipseCon this week, along with my workmate Gaétan Morice, so please feel free to come ask us further information on Koneki. Also, we will run a “Machine-to-Machine at Eclipse” BoF on Wednesday, 7.30pm (be careful, the room is likely to change). The aim of the BoF will be to discuss not only the requirements for an M2M IDE – which is the scope of Koneki, but, more generally, what an M2M reference environment should be: standard client/server communication protocol(s), programming model, component model, etc.

Oh, and by the way, Koneki is a Maori word meaning “here”, “this place” ; and is  a great metaphor of M2M: you communicate with many remote devices without moving from where you are.

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

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

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:

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

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

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…

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!

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:

 #!/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 "*.gif" -print | zip ~/public_html/eclipse-icons.zip -@ 

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…

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…

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 !

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 !

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.

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

Thus, deployment needs are not limited to installing and updating only plug-ins anymore. People building software on top of Eclipse need to be able to deliver an installer for their product, which may come with a license manager which needs provisioning too, they need to have their own UI for the updating process, … and p2 answers to virtually all these needs.

p2: a provisioning platform…

To be able to provision virtually everything, the main strength of p2 is to have no a priori knowledge of the way Eclipse plug-ins or even Java applications must be handled. It’s indeed a very light framework to describe the parts that are to be installed (the Installable Units), and how they depend on each other. p2 comes with some basic instructions about how an OSGi bundle or an Eclipse product should be installed, but nothing else.

It’s up to the software vendor who wants to deliver, let’s say, a Windows executable program (which may require adding keys to the registry, or icons on the desktop, for instance) together with its Eclipse RCP application, to write the code (in fact, a p2 plug-in!) to explain p2 how this particular Installable Unit should be handled when provisioned in a given system.

… and, the next deployment standard?

Of course, although p2 is still a very young project, and may not seem mature enough for industrial usage. It is still not 100% reliable yet and lacks tooling, but the quality of this very first release is still pretty high. Since it was released, p2 has started gathering a community which is leveraging p2 in other domains than just the Eclipse project itself. Software companies like Cloudsmith, EclipseSource and Anyware Technologies are already developing tools on top of p2 ; and IBM, among others, is working hard to improve the p2 core and design a clear API.

The massive adoption of OSGi in many different areas (Eclipse runtime technologies like Equinox itself or RAP, applications servers like Websphere or Glassfish, etc.) will definitely make p2 the smartest way to deploy not only Eclipse-based applications, but any sort of scalable application as well. Indeed, when high availability is an important requirement (in other words — almost always), then you need to be able to dynamically install new modules into the running system, update existing ones, sometimes even do this remotely.

Since there is currently no real sustainable alternative for industrial deployments – did you ever try to use Java Web Start for more than just a very simple Swing or RCP application? – p2 will probably come up as a de facto provisioning technology standard.

Si le travail de certains contributeurs ou committers vous a particulièrement impressionnés, si des membres de la communauté font selon vous un travail d’évangélisation et de promotion d’Eclipse qui mérite d’être cité, alors n’hésitez pas à aller vous exprimez sur les bugs correspondants du bugzilla Eclipse!

Pour faire court, si vous avez un JDK 1.6 ou supérieur, il ne vous faudra que quelques secondes pour obtenir un état de la pile, puisqu’il suffit d’exécuter :

• jps, afin d’obtenir le PID de la JVM qui vous intéresse
• jstack <pid>, pour obtenir le dump sur la sortie standard

Avec une version de JDK plus ancienne, il faut avoir lancé la JVM (de Sun…) avec l’option -Dcom.sun.management.jmxremote. Cela permet de s’y connecter par la suite avec l’outil jconsole. Bien qu’assez peu contraignante, cette pratique a tout de même l’inconvénient d’obliger à savoir à l’avance que l’application va tomber dans un deadlock, ce qui n’est pas toujours le cas…

Si vous êtes sous Linux, vous avez gagné puisque quelle que soit votre version de Java, un kill -3 <pid_JVM> fonctionnera à coup sûr !

Le wiki détaille d’autres procédures, et notamment comment s’y prendre si l’on veut obtenir le dump d’une application à distance.

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!

Attention, ces entrepôts ne sont pas ceux de Ganymede et de Galileo, ils contiennent simplement le SDK Eclipse !

Platform 

• La sélection par bloc dans les éditeurs texte fait enfin son apparition (un bug était ouvert depuis… 2002 !), et c’est un grand soulagement pour tous les développeurs Cobol !
  Plus sérieusement, cette fonctionnalité peut faire gagner énormément de temps quand on a besoin de bidouiller des fichiers CSV, par exemple…

• On peut désormais associer des icônes à des entrées de la table des matières

JDT

• De même que l’on pouvait déjà coller le contenu d’une classe Java qu’on aurait copié dans son presse-papiers, on peut désormais directement appliquer un patch en le collant n’importe où dans son Package Explorer !

p2

• L’IHM de p2 a été pas mal remaniée pour encore plus simplifier son utilisation. N’hésitez pas à faire des retours sur cette page du wiki Eclipse.

PDE

• Le PDE/Build supporte désormais la compilation “multicore” introduite dans JDT avec Ganymede. Ainsi, PDE Build va détecter les grappes de plug-ins complétement indépendantes, et les compiler en parallèle.
  Allez donc jeter un oeil ici pour plus de détails sur la façon (ultra-simple !) d’activer cette fonctionnalité dans vos builds.
• L’éditeur graphique de Declarative Services OSGi est encore et toujours amélioré (pour rappel, c’est un des principaux chantiers du PDE pour cette version 3.5)

• Dans les assistants d’export de plug-ins et de features, on peut demander à directement installer les fonctionnalités exportées… dans son environnement de développement !
  C’est une fonctionnalité très intéressante, mais qui n’a malheureusement qu’un intérêt plus limité quand on n’est pas développeur d’Eclipse-même…

Pour le New&Noteworthy complet, c’est ici ; les téléchargements étant eux… là-bas !