Le wiki eclipse.org propose un fichier intitulé common_wizard_elements.svg.

On y trouve pas mal d’icônes qui peuvent convenir pour une présentation. Seulement c’est un fichier Adobe Illustrator. Jusqu’à présent, j’avais extrait quelques icônes à la main à l’aide d’Inkscape et de GIMP (n’étant pas graphiste, je ne vais pas investir dans des logiciels payants que je ne maitrise pas).

Comme j’en avais assez de faire ce travail de découpe d’image à la main, j’ai imaginé un moyen de faire autrement. Après pas mal d’essais, j’ai trouvé une formule qui convient :

• Conversion au format svg par Inkscape.
• Petit script en java pour faire de la transformation de fichiers XML. J’arrive à découper le fichier initial en petit fichier svg correspondant à une icône.
• Conversion svg => png à nouveau avec Inkscape.

Le résultat me convient. J’ai mes icônes au format svg et png dans des fichiers indépendants. Chaque icône est proposée avec un cadre ou non, avec le fond d’origine ou un fond transparent. Quelques exemples:

Le tout est partagé sur GitHub dans le projet common_wizard_elements.

Pour ceux qui veulent juste récupérer les images, des fichiers zip contenant les icônes sont en téléchargement sur Bintray.

Les plus attentifs remarqueront que je n’ai pas mis de licence sur les images produites. En fait, j’attends une réponse de la fondation Eclipse pour connaître la licence du fichier original. Mes fichiers seront certainement partagés avec cette même licence.

EasyEclipse est un projet d’IDE Java payant, une version modifiée de l’IDE open source Eclipse, spécialement conçu pour travailler efficacement sur du code java.
Je viens de soutenir le le projet sur Kickstarter. Voici pourquoi.

Où est le problème de l’IDE Eclipse ?

Depuis un certain temps, la communauté s’interroge sur la viabilité de l’IDE Eclipse. Quelques billets de blogs (automne 2013) :

• Imagine the eclipse IDE would cost $300…
• The Tragedy of The Eclipse Commons and Taxation ainsi que son autocritique une semaine plus tard
• Evolution of Cooperation

J’ai moi aussi déjà eu l’occasion d’écrire sur Google+ ce que j’en pensais.

Le nœud du problème est très simple :
Longtemps, les briques fondamentales d’Eclipse ont été entretenues en majorité par IBM. Aujourd’hui, ce n’est plus le cas. Beaucoup d’entreprises profitent d’Eclipse et de son écosystème : soit en réutilisant certains éléments de la plateforme pour construire quelque chose d’autre (un complément à Eclipse ou un autre produit), soit en tant qu’utilisateur de l’IDE ou d’un des outils dérivés. L’IDE ou les autres outils sont souvent gratuits, du coup il n’y a que très peu de contribution en retour.

La fondation Eclipse n’est pas là pour s’occuper de l’IDE. Il suffit de relire le document mission statement de la fondation, pour s’en rendre compte. Il ne figure nulle part « Eclipse IDE » ou « Éditeur de code Java ». Ce n’est malheureusement pas clair pour tout le monde.

Je suis curieux de savoir ce que Mike Milinkovich va dire lors de sa Keynote Eclipse: The Next 10 Years durant la prochaine EclipseCon. En lisant son blog, on comprend que l’IDE en tant que produit, n’est pas la priorité de la fondation. Dans cet article retour de JavaOne 2013 je lis en creux « Eclipse IDE n’est pas vraiment présent à JavaOne, ce n’est pas grave, car l’avenir de la fondation est ailleurs ». L’article sur les dix ans de la fondation n’est pas plus rassurant.

Je ne dis pas que la raison d’être de la fondation est une mauvaise chose. La fondation Eclipse est là pour que des acteurs se rencontrent, des choses soient possibles, du code open source garanti soit produit, en garantissant certaines choses comme la neutralité vis-à-vis des entreprises participantes. Les projets autour de l’IDE ne sont que quelques-uns parmi d’autres. À ce titre, les dernières initiatives comme Internet of Things ou Location Tech sont certainement bonnes pour la fondation, pour l’open source… Mais elles n’apportent rien à l’IDE Java qu’est Eclipse.

Et l’open source dans EasyEclipse ?

À titre personnel, j’aurais préféré soutenir une fondation ou une association. Pour moi Mozilla ou la Document Foundation sont de bons exemples d’organisations garantes d’un ou plusieurs produits. Cela existe! Pour moi il faudrait une organisation pour soutenir l’IDE Eclipse. Cela ne serait pas incompatible avec la fondation Eclipse, mais complémentaire. Mettre ce genre d’organisation en place demande beaucoup d’énergie et d’efforts, et je comprends que personne ne veuille se lancer.

Quelque part, un entrepreneur avec une vision, une idée de produit, un modèle économique est plus à même de tenter l’aventure. Pour réussir, EasyEclipse doit être un business. Mais ce n’est pas forcément une mauvaise chose, car business est aussi garant de pérennité. Dans son modèle, Pascal et son équipe s’engagent à soutenir les projets open source de la fondation Eclipse utilisés pour réaliser EasyEclipse.

Dans un premier temps (celui de la campagne de financement) entre 20% et 30% de la somme levée seront consacrés à améliorer les projets Eclipse nécessaires à la réalisation d’EasyEclipse. Je fais confiance à Pascal Rapicault pour investir cette somme correctement. Espérons que les retombées soient grandes pour tout l’écosystème. D’autant plus que je pense rester, au moins pendant mon temps de travail, un utilisateur de l’IDE Eclipse plutôt que d’EasyEclipse.

Le projet Kickstarter doit permettre de prouver la viabilité du modèle EasyEclipse. Je crois au modèle du financement participatif pour financer certaines fonctionnalités de projets open source. EasyEclipse va plus loin, car la campagne de financement doit permettre de créer un projet qui attire des utilisateurs pour atteindre un autofinancement (les licences financent l’évolution du produit).

Le danger pour l’open source, c’est qu’EasyEclipse devienne un fork de certains projets de l’IDE sans aucune contribution en retour. Il me semble que ce n’est pas l’idée.

À moyen terme, en cas de succès, je me dis qu’un projet comme EasyEclipse peut être le moyen pour certaines entreprises, qui utilisent la plateforme Eclipse, de financer une partie de son évolution. Pour de nombreuses entreprises, l’IDE Eclipse est déjà un investissement (outil de travail quotidien, formation des collaborateurs…) et il a déjà un coût (rien que celui de changer d’IDE si Eclipse n’évoluait plus). Pour elles, donner une certaine somme d’argent pour résoudre les problèmes qui font perdre du temps au quotidien peut être un bon calcul avec un retour sur investissement direct. Pour qu’elles puissent le faire, il faut une ou plusieurs structures identifiées en mesure d’apporter une réponse et de mutualiser l’effort. EasyEclipse pourrait être un début de réponse.

Pascal Rapicault

Je ne connais pas Pascal Rapicault personnellement. Je l’ai croisé à l’EclipseCon, mais je ne suis pas certain de lui avoir parlé. Je suis entièrement d’accord avec Cédric Brun qui voit en lui la bonne personne pour se lancer dans cette aventure : c’est un développeur qualifié avec une bonne connaissance de la plateforme.

Si la campagne de financement est un succès, un certain nombre de clés seront entre les mains de Pascal (choix stratégiques, réussite ou non du projet). Comme toujours dans le cas du financement participatif, au final, c’est une question de confiance.

Parlez-en autour de vous

Comme pour tous les projets de financement participatif. Pour que cela marche, il faut en parler.

Maintenant, c’est l’heure de vérité : les idées évoquées ici et là sur des blogs et des mailings listes sont confrontés à la réalité : est-ce possible de trouver suffisamment de personnes motivées pour donner quelque chose ?

Je pense que si EasyEclipse marche, la communauté Eclipse et son écosystème ne seront pas déçus par la confiance accordée.

EasyEclipse sur Kickstarter.

Sauf erreur de ma part, ça n’existe pas… En tout cas, je ne l’ai pas trouvée… Je me suis donc amusé à générer chacun des exemples (projet org.eclipse.birt.chart.examples) et à les mettre en ligne sur mon espace développez. C’est tout simple, mais efficace.

http://jmini.developpez.com/eclipse_birt/charting_engine/gallery/

Le résultat obtenu fait tout de suite beaucoup plus professionnel :

J’avais déjà utilisé JFreeChart il y a longtemps… Mais BIRT étant un projet Eclipse sous licences EPL, je l’avais mis depuis longtemps sur ma liste des choses à regarder. Le projet Eclipse BIRT est assez vaste, en fait c’est une solution de Business Intelligence complet qui est comparable à la suite Jaspersoft. Je me concentre ici sur le module Eclipse Charting Engine de BIRT : c’est lui qui dessine les diagrammes et qui est donc plus comparable à JFreeChart.

Finalement, ces librairies fonctionnent de la même manière. Au travers d’une API le modèle du diagramme est défini : le type de diagramme, les différentes séries qui vont être représentées, les éléments graphiques (couleur, légende, titre…).
Pour s’en sortir, rien ne vaut une petite recherche Google pour trouver les extraits de codes qui permettent de partir d’un exemple déjà défini. Je suis surpris de ne pas trouver de galerie présentant les différents types de diagramme (histogramme, diagramme circulaire…). D’autant plus qu’il existe un projet contenant des exemples: org.eclipse.birt.chart.examples

Rapidement j’ai obtenu ce que je souhaitais… La plus grande difficulté concerne les dépendances… En fait le morceau de code que j’avais trouvé marchait bien en Java SE, mais j’ai mis un certain temps à comprendre comment cela fonctionnait dans mon application Eclipse Scout. Sans y faire attention (ayant copié collé du code venant de StackOverflow), j’utilisais le mode STANDALONE de BIRT. Dans une application Eclipse Scout, on est évidemment dans un contexte OSGi.

Aller plus loin :
Pour aller plus loin, il me semble que passer par le champ SVG d’Eclipse Scout n’est pas vraiment une bonne solution. D’après ce que j’ai vu, BIRT dispose de widgets d’affichage pour Swt et Swing. Il serait plus malin d’avoir un ChartField dans Eclispe Scout avec les renderer appropriés.

Une autre réflexion à mener concerne la répartition client server de la logique de diagramme. Il me semble que BIRT propose un découpage plutôt intéressant qu’il serait possible de reprendre en réfléchissant à l’intégration client/serveur.

Au final l’utilisation d’Eclipse BIRT Chart-Engine se révèle être une bonne expérience.

Pour moi, chacune de ces EclipseCon m’a donné la possibilité de rencontrer des gens, de replacer les choses dans leur contexte, de réexpliquer notre projet en partant du début… Voici quelques réflexions que je souhaite partager ici.

A la différence d’autres stands consacrés à la promotion d’outils payants, nous présentons un projet Eclipse. J’ai été surpris de voir qu’il y a toujours de la pédagogie à faire. Un projet Eclipse cela signifie : du code open-source, du code dont la licence permet une réutilisation, y compris dans des projets commerciaux, et enfin du code dont la propriété intellectuelle a été contrôlée. Plusieurs fois les visiteurs du stand n’imaginaient pas qu’ils allaient pouvoir utiliser ce que nous montrons gratuitement, sans aucun engagement. Evidemment mon entreprise propose des préstations commerciales autour des projets Eclipse. Mais ce n’est qu’une possibilité, pas une obligation.

Pour Eclipse scout les signaux sont bons. J’ai présenté ce framework la première fois en 2011 lors d’un Eclipse Day à Paris. A l’époque il fallait beaucoup justifier ce que nous proposions. Même si le projet Scout existe en interne dans notre entreprise depuis plus de 10 ans, passer en open-source c’est se trouver sur la place publique au milieu de tout ce qui existe déjà. Aujourd’hui davantage de gens nous connaissent déjà ou ont envie de savoir qui nous sommes. Nous avons des éléments tangibles pour montrer ce que nous faisons : nos applications de démonstration, notre forum, notre livre à télécharger (voir aussi les premiers retours sur le livre eclipse scout).

Parler avec les visiteurs de la conférence, c’est l’occasion de se (re)définir : nous sommes un framework pour réaliser des applications métiers, avec une architecture client-serveur. Notre force est de ne pas dépendre d’une librairie graphique en particulier, mais de proposer une couche d’abstraction dans laquelle nos formulaires sont définis. Cela permet de suivre les évolutions du marché sans avoir à tout réécrire. Les applications que nous développons avec Eclipse Scout ont un cycle de vie assez long : disons au-delà de 10 ans. Or les librairies graphiques, les plateformes applicatives, les attentes des utilisateurs en termes de charte graphique évoluent. Pouvoir en profiter, en mutualisant les coûts au niveau d’un framework est un avantage. C’est le message que mes collègues ont essayé de faire passer durant leur talk.

Montrer Eclipse Scout c’est l’occasion de redécouvrir ce que nous faisons et ce que nous proposons. Le premier soir j’ai relu mes articles de 2011 sur ce blog. Beaucoup de choses sont toujours valables. De plus à l’époque j’avais une vision neuve du projet. Les applications Eclipse Scout disposent par défaut de plusieurs éléments vraiment intéressants pour les utilisateurs finaux. Par exemple toutes les tables qui affichent des données peuvent être réorganisées par les utilisateurs (tri multiple, filtre, ordre des colonnes…). Il est facile d’y brancher un export vers Excel. Les champs de saisie disposent de nombreuses petites fonctionnalités qui facilitent le travail au quotidien. Ce sont des avantages indéniables pour les utilisateurs des applications réalisées avec Eclipse Scout. Cela leur facilite la vie dans leur travail quotidien. Sans Eclipse Scout, ce sont autant de choses qu’il faudrait redévelopper à chaque fois.

Un dernier très bon moment de ce dernier EclipseCon en Allemagne : mon interview avec InfoQ France… Une vidéo devait bientôt être mise en ligne.

Je n’ai pas résisté à l’envie de mettre quelques photos :

En anglais, ce livre donne un bon aperçu des possibilités d’Eclipse scout au travers de deux tutoriaux. Un chapitre est consacré aux outils « Scout SDK » intégrés à Eclipse, qui permettent un accès facile à Eclipse Scout et un développement efficace. Le tout commençant par un chapitre d’introduction donnant en quelques pages une description d’Eclipse Scout et sa philosophie.

J’avais envie de partager quelques notes sur les coulisses de rédaction du livre.

L’infrastructure du livre a été pensée avec les valeurs de l’open source. Le code est sur GitHub, le contenu est au format Creative Commons (CC-BY), les scripts de compilation sont fournis (les livrables sont générés avec LaTeX).

Si durant la phase de rédaction il a eu peu de retours, le fait de « sortir » une première version du livre a fait bouger les choses. Les premières contributions arrivent : certaines personnes souhaitant creuser certains sujets ont posé des questions dans notre forum. D’autres ont ouvert des tickets sur GitHub pour signaler des coquilles de frappe. Enfin les personnes les plus à l’aise avec Git et GitHub ont envoyés des changements par commit git. Ces retours ont de la valeur. Ils améliorent le produit final.

Il s’agit d’une première version. Certaines ambitions ont dû être revues à la baisse pour pouvoir sortir cette version en coïncidence avec le release train Eclipse (Kepler en juin 2013). L’idée est de fixer les bugs sur la version Kepler et d’enrichir le livre dans le courant de l’année pour revenir en juin 2014 avec une version Luna plus étoffée.

C’est une possibilité de plus qui confirme la stratégie multi front-end d’Eclipse Scout. En effet la même application peut-être rendue sous différente forme : application desktop, application web et maintenant application web mobile.

Depuis toujours, une idée principale d’Eclipse Scout consiste en une surcouche pour définir l’application qui soit indépendante de toute librairie graphique (SWT ou Swing). Les formulaires ainsi que les champs qu’ils contiennent sont définis dans un modèle d’application qui sera rendu sous forme d’interface graphique à l’exécution. Cette technique permet d’obtenir plusieurs déclinaisons de la même application :

Version SWT :

Version Swing :

Version web :

Le mobile étant une plateforme différente, il a fallu ajouter une étape supplémentaire lors du rendu. Les composants sont adaptés pour tenir compte des spécifiés de la plateforme. Voici quelques exemples :

Smartfield :

Le smartfield est un champ assez puissant : à la manière d’un combo-box, il permet de choisir parmi plusieurs choix. Il est également possible de saisir du texte dans le champ pour réduire les choix proposés. En version mobile, pour reproduire toutes ces possibilités, il a fallu ajouter une vue annexe sur la droite.

Absence de menu contextuel :

L’action proposée dans le menu contextuel apparait sous forme de bouton sous la table.

Représentation des tableaux :

La largeur offerte par le téléphone est limitée. La hauteur des lignes d’un tableau doit être suffisante pour permettre une sélection avec le doigt « sélection touch ». Du coup, les colonnes d’un tableau sont rassemblées sous forme de lignes dans une cellule plus haute. Les colonnes d’une ligne du tableau vont être représentées dans un formulaire annexe accessible en sélectionnant une cellule dans la liste mobile.

L’action principale du menu contextuel (celle qui aurait été proposée en double cliquant sur la ligne du tableau) et qui correspond souvent à l’opération d’édition se retrouve déportée en haut à droite. Les opérations restantes sont disponibles dans un menu supplémentaire.

Masquer certaines fonctionnalités :

Toutes les fonctionnalités ne font pas forcément sens sur mobile. Pour mon application, j’ai décidé de masquer la représentation sous forme graphique (déjà rudimentaire dans la version desktop) en supprimant l’onglet correspondant.

En conclusion

Cette transformation du modèle applicatif permet d’adapter le rendu web aux spécificités du mobile. Évidement l’application obtenue n’est pas aussi efficace qu’un développement dédié, mais le résultat est plus que convainquant par rapport au temps investi.

Photo: Morceau de sucre par zigazou76 (CC BY 2.0)

Cette expression de sucre syntaxique me laisse perplexe. Le fait est qu’améliorer la lisibilité du code est un des objectifs d’Xtend. Tout en conservant tous les concepts de Java, Xtend va en simplifier l’écriture et la lecture.

Essayons d’analyser cet extrait de code…

Les points virgules en fin de ligne sont facultatifs. Avant de faire du Xtend, je ne les avais jamais vraiment considérés comme gênants. Maintenant, je me surprends à écrire du Java dans lequel ils manquent.

Également facultatif : les parenthèses pour les méthodes sans paramètres. C’est bien pratique pour instancier un objet dont le constructeur n’attend pas de paramètres. Il suffit d’écrire new Actor.

Xtend fait de l’inférence de type partout où c’est possible. Au final je peux presque toujours me passer de type lorsque je déclare mes variables avec le mot clé val (pour les variables non mutables, finale en Java) ou le mot clé var (pour les variables classiques de Java). C’est vrai aussi pour le type retourné par une méthode. Pas besoin de le définir, il est déduit du contenu de la fonction.

L’utilisation des getters et setter est simplifié : il est possible d’accéder à la valeur retournée par un getter directement. Typiquement actor.lastName correspond en Java à actor.getLastName(). De même actor.firstName = "Bob" utilisera le setter comme on s’y attend.

En fait cette invocation des méthodes avec l’opérateur égal marche avec toutes les méthodes d’une classe. C’est pour cela que je peux écrire actors.add = actor si actors est une liste de type List et actor un objet de type Actor.

Le mot clé return peut également être omis… La dernière expression évaluée est ainsi retournée. Au début je me disais que ce n’était certainement pas une bonne idée. Et puis je me suis surpris à l’utiliser dans les méthodes très courtes (celles qui retournent juste une valeur).

Je ne suis pas certain que ces différents exemples constituent une liste exhaustive de la simplification de syntaxe qu’apporte Xtend. En écrivant cet article, je me rends compte qu’il ne s’agit que de la surface visible de l’iceberg : je n’ai pas du tout évoqué d’autres aspects que j’adore dans Xtend (Extension Methods, Operator Overloading, With Operator, Template Expressions… Autant d’autres sujets possibles pour ma série d’articles sur Xtend).

De toutes ces possibilités, il y a certainement un certain nombre de bonnes pratiques à définir dans une équipe de développement. Il ne faudrait pas que les possibilités de simplification offerte par le langage aboutissent à l’écriture de code illisible.

5 Things That Make Xtend a Great Language for Java Developers
Comme indiqué dans le titre, l’auteur liste 5 points d’Xtend qui en font un bon langage pour les développeurs Java :

1. Compilation en java
2. L’inférence de type
3. Les méthodes extensions
4. Les lambdas
5. Le templating

Chaque point est accompagné d’un texte de présentation et de petits exemples.

Xtend: the better compromise
Un article qui prend un peu de recul sur Xtend et ses concepts. C’est un article bien construit, qui explique le contexte et apporte un retour d’expérience. L’auteur a classé les différents points selon ce qu’il apprécie, ce qui est moyen, ce qu’il n’aime pas et ce qu’il aimerait voir. Un très bel aperçu des enjeux de ce langage.

A better Java: Scala or Xtend?
Comme Scala et Xtend revendiquent chacun le slogan « A better Java », cet article compare les deux langages. L’article détaille certaines constructions syntaxiques. Pour chacune d’entre elles, un comparatif est proposé ainsi que l’avis de l’auteur.

Eclipse Xtend: Java’s equivalent to CoffeeScript
Une interview de Sebastian Zarnekow et de Sven Efftinge, les deux concepteurs du langage et des outils dans Eclipse à propos d’Xtend. Cette interview menée par jaxenter revient sur le projet, sa raison d’être, ses origines, ses perspectives.

Rebel Labs interview: Sven Efftinge founder of Xtend
Cette interview est un bon complément à la précédente. Elle est plus récente et va plus en profondeur sur un certain nombre de sujets. Elle confirme selon moi que Sven est un développeur brillant et qu’il sait où il veut mener le projet Xtend.

Cet article est destiné à être mis à jour.

À travers cette série d’articles sur Xtend, j’aimerais montrer les possibilités du langage.

Installation:
Je ne souhaite pas m’étendre sur les différentes possibilités d’installation. Cela fonctionne comme n’importe quel autre projet Eclipse.

Une version packagée existe également sur la page des téléchargement d’Xtend (choisir « Full Eclipse »). Elle contient la bonne version de chaque composant. C’est cette version qui est la plus simple pour débuter.

Un premier exemple:
Xtend s’utilise d’un projet Java traditionnel. Il suffit de créer une nouvelle classe Xtend dans un package.

Eclipse se charge alors de compiler ce code en fichier java (code source java), qui se trouve placé dans le dossier xtend-gen à côté du dossier src.

Un Bean Java (des fields java privé avec des getters et setters associés) peut s’écrire en Xtend de la manière suivante:

Le fichier java correspondant: