Journal Plugin Eclipse : Jean qui rit et Jean qui pleure?

Posté par Guillaume ALAUX (site web personnel) le 12 juillet 2010 à 18:23.

Étiquettes : aucune

juil.

2010

De la puissance et de la simplicité d'utilisation
Eclipse est l'environnement de développement multi langage que l'on ne présente plus. C'est l'IDE (Integrated Development Environment) incontournable du Java qui reignait sans partage sur les environnements de développements il y a encore quelques années avant que n'arrivent des concurrents sérieux. Le succès d'Eclipse doit beaucoup à son fonctionnement en plugins, ces extensions de fonctionnalités du logiciel de base qui permettent d'améliorer la plate-forme plutôt que de se lancer dans un développement from scratch d'une autre solution.
L'idée est alléchante : un logiciel générique qui se voit spécialisé par des plugins pour se transformer en IDE adapté aux spécificités de tel ou tel langage, telle ou telle technologie. Et dans ce domaine Eclipse est roi. On peut le transformer en tout ou presque : un éditeur avancé Java pour développer des clients lourds ou applications client/serveur, un éditeur de rapport (Birt), un client Subversion, un outil d'aide à la gestion de projet (Remus) etc.

Il m'avait été demandé il y a quelques années de développer une interface graphique pour un outil de validation syntaxique de XML et le choix s'est porté sur un plugin Eclipse ce qui permettait de réutiliser les capacités avancées d'éditeur de texte d'Eclipse. En quelques temps nous avions ainsi un éditeur de texte avec coloration syntaxique XML, et tous les copier/coller et pliages/dépliages (folding) d'éléments XML nous évitant ainsi d'avoir à redévelopper ces fonctionnalités s'il avait fallut faire un logiciel from scratch. On trouve d'ailleurs beaucoup de tutoriels sur internet qui permettent d'arriver à ce résultat rapidement.
Le déploiement sur le poste utilisateur du résultat est de plus un vrai plaisir via l'Eclipse Update Site. Saisissez simplement sous Eclipse l'URL du site de l'éditeur du plugin qui vous intéresse et quelques "Suivant" et un redémarrage d'Eclipse plus tard vous amèneront devant votre IDE agrémenté de la fonctionalité souhaitée.

Que diable allait-il faire dans cette galère ?
Mais malheureusement tous les besoins ne trouvent pas leur réponse dans le simplissime tutoriel qui permet de créer un éditeur de texte de base et il faut alors se plonger dans la documentation de la bibliothèque des composants visuels d'Eclipse : Standard Widget Toolkit (SWT). Il faut aussi se familiariser avec les concepts d'extensions et points d'extension qui permettent de se brancher sur la plateforme Eclipse et de proposer d'autre points de branchement pour de futurs plugins. Car ceux-ci s'assemblent entre eux pour donner des suites logicielles complètes tel Birt, Web Tools Platform, JBoss Tools qui sont chacun un aggrégat de plusieurs dizaines voir centaines de plugins à chaque fois. Web Tools platform par exemple est l'aglomération de plus de 400 plugins!

Et ce qui ressemblait à un joyeux Légo peut vite se transformer en puzzle de plugins à chaque fois nécessaires dans une version très précise ce qui se termine souvent sur le problème très connu de la gestion des dépendances. Les équipes de développement en sont souvent réduites à mettre en place leur environnement de développement avec les versions courantes des plugins puis à garder précieusement une archive du répertoire Eclipse. Ce "gel" de l'environnement de développement permettra par la suite d'installer un nouveau poste de développement avec les versions exactes des plugins nécessaires pour le projet. À partir de ce moment il n'est plus question de mettre les à jour plugins sous peine de voir s'écrouler le fragile environnement de développement Java.

Les plugins Eclipse sont une alternative puissante au développement from scratch d'une application dont beaucoup de composants existent déjà. Mais ils constituent un état dans l'état Java et dans ce contexte on ne s'étonnera plus de voir, des offres d'emploi de "développeurs de plugin Eclipse" plutôt que de "Développeurs Java". L'expérience semble en effet montrer que "non", un développeur Java "Classique" ne possède pas les connaissances suffisantes pour développer un plugin Eclipse, tellement ces derniers sont spécifiques.

# Expert

Posté par stopspam le 12 juillet 2010 à 18:56. Évalué à 10.

L'expérience semble en effet montrer que "non", un développeur Java "Classique" ne possède pas les connaissances suffisantes pour développer un plugin Eclipse, tellement ces derniers sont spécifiques.

La similitude est frappante avec d'autres langages :
- on ne cherche plus un développeur python mais un développeur Django
- on ne cherche plus un développeur php mais un développeur Symfony
- ...
- [^] # Re: Expert
  
  Posté par Corentin Chary (site web personnel) le 12 juillet 2010 à 19:45. Évalué à 10.
  
  Alors qu'a priori, chercher un "bon" développeur (qui sait encore apprendre des choses tout seul) sera probablement plus rentable sur le long terme (>6 mois) qu'un "développeur de plugin Eclipse".
  
  Je trouve ça lourd les "ah, vous connaissez pas ça ? bah inutile de postuler ici". Alors qu’a priori, l'important c'est pas tant la connaissance d'une techno précise qui importante, mais l’ensemble du "background" de la personne.
  
  Par exemple, le type il connais trop bien l'API pour faire des plugins Java, mais il a aucune notion de complexité algorithmique, et du coups, il va se retrouver a faire un plugin qui bouffera toute la ram (ou le cpu, au choix).
  
  Enfin bon ... forcément, c'est sûrement plus facile pour les recruteurs de faire comme ça.
  - [^] # Re: Expert
    
    Posté par Olorim le 12 juillet 2010 à 20:35. Évalué à -2.
    
    Alors qu'a priori, chercher un "bon" développeur...
    Ca existe ça? C'est comme le père Noël non?
    
    Ok, ok, pas taper! ----------------------->[ ]
    - [^] # Re: Expert
      
      Posté par Moogle le 13 juillet 2010 à 12:18. Évalué à 7.
      
      Bah oui, un bon développeur, il a un projet à faire, il le code. Alors qu'un mauvais développeur bah... il a un projet à faire, il le code, mais bon, c'est un mauvais développeur.
      - [^] # Re: Expert
        
        Posté par Gniarf le 13 juillet 2010 à 18:38. Évalué à 2.
        
        et ça donne du mauvais code et un projet mal réalisé. on les reconnait plus facilement, du coup.
      - [^] # Re: Expert
        
        Posté par Moonz le 13 juillet 2010 à 19:01. Évalué à 9.
        
        Le bon développeur, il connaît son besoin, et fait son programme en deux heures et 5 lignes de Perl (mais quelles lignes).
        Le mauvais développeur, il lance Eclipse, commence par faire des diagrammes de classe et en se retrouvant avec des StubFactoryFactoryProxyImpl au moment d’implémenter son système d’abstraction des plugins de son système de liaison dynamique GUI-DAO, puis, au bout de 6 mois, clique sur le bouton « générer les classes », et se demande : « mais au fait, je voulais faire quoi moi ? »
        
        [^] # Re: Expert
        
        Posté par LeBouquetin (site web personnel, Mastodon) le 14 juillet 2010 à 00:40. Évalué à 1.
        
        Moonz, tu serais administrateur système qui développe lui-même (et mieux que les autres) ses outils en PHP que ça ne m'étonnerait pas.
        #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
        
        [^] # Re: Expert
        
        Posté par Moonz le 14 juillet 2010 à 16:24. Évalué à 3.
        
        J’ai le regret de vous informer que votre boule de cristal est défectueuse et doit être remplacée dans les plus brefs délais.
        
        Cordialement,
        
        IRMA&co., Service après-vente.
  - [^] # Re: Expert
    
    Posté par Quikeg le 13 juillet 2010 à 12:14. Évalué à 2.
    
    Oui surtout si le recruteur qui trie les CV est un bon vieux RH qui sait bien lire les descriptifs de poste venant des opérationnels mais n'a aucune idée de ce que c'est que Eclipse (rôh le vieux cliché).
# WTP inempaquetable

Posté par Davy Defaud le 12 juillet 2010 à 20:30. Évalué à 5.

La complexité des dépendances de WTP est telle que les "empaqueteurs" des distros n'ont jamais été en mesure de faire des paquets eclipse-wtp. Ni pour Fedora, ni pour Mandriva (normal, car les paquetages Eclipse sont dérivés de ceux de Fedora), ni pour Debian. Ce qui est assez ennuyeux pour les utilisateurs finaux que nous sommes.
Si tu veux faire du PHP avec eclipse-pdt, tu as besoin de WTP. Le seul moyen d'avoir un truc qui marche c'est de télécharger le ALL-IN-ONE pour PDT. Le problème c'est que si tu veux aussi faire du java ou du C, ben ton ALL-IN-ONE pour PDT ne suffira pas et tu auras beau essayer d'installer des plugins avec les sites de mise à jour gérés par Eclipse (qui accessoirement ont l'énorme défaut de ne pas permettre d'installer les plugins en multi-utilisateur, mais uniquement pour l'utilisateur effectuant l'installation des plugins), tu retomberas sur des problèmes de dépendances quasi insolubles. Ou alors, il te faut installer un ALL-IN-ONE par usage en parallèle des autres : super optimal !
S'il y a un truc lourdingue avec Eclipse, c'est bien ce problème de gestion des dépendances.
Comparé à Netbeans, sur ce point précis, il n'y a pas photo.
- [^] # Re: WTP inempaquetable
  
  Posté par barmic le 12 juillet 2010 à 21:35. Évalué à 2.
  
  Je ne sais pas si c'est du à OSGI mais le couplage est trop fort entre les plugins.
  
  Ce qui pourraient les sauver pour ce genre de choses c'est d'avoir des profils. Mais très franchement ça me ferrait peur avec la philosophie que semble avoir eclipse...
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: WTP inempaquetable
    
    Posté par Guillaume Knispel le 12 juillet 2010 à 22:38. Évalué à 5.
    
    Votre dialogue comportant moultes sigles cabalistiques et en tout cas imbitable si on ne connaît pas Eclipse, ou alors que de très loin.
    - [^] # Re: WTP inempaquetable
      
      Posté par barmic le 12 juillet 2010 à 23:33. Évalué à -2.
      
      OSGi n'est pas un sigle. C'est le nom d'une technologie Java servant à la modularisation et permet de créer des plugins. Wikipedia t'en diras bien plus que moi : https://secure.wikimedia.org/wikipedia/fr/wiki/Osgi
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: WTP inempaquetable
        
        Posté par allcolor (site web personnel) le 13 juillet 2010 à 00:26. Évalué à 1.
        
        Ben si OSGi est un sigle... C'est "Open Services Gateway initiative".
        
        [^] # Re: WTP inempaquetable
        
        Posté par barmic le 13 juillet 2010 à 00:38. Évalué à -2.
        
        C'était un sigle, maintenant c'est un nom.
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: WTP inempaquetable
        
        Posté par barmic le 13 juillet 2010 à 13:15. Évalué à 1.
        
        Moinssinez moi comme bon vous semble. Je l'invente pas, je le tiens de Didier DONSEZ président de "OSGi Users Group France".
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: WTP inempaquetable
        
        Posté par boq le 14 juillet 2010 à 03:26. Évalué à 4.
        
        OSGi Users Group France
        OSGiUGF, c'est un sigle ou c'est un nom?
      - [^] # Re: WTP inempaquetable
        
        Posté par Guillaume Knispel le 13 juillet 2010 à 04:54. Évalué à 2.
        
        WTP, ALL-IN-ONE, PDT (pomme de terre???) ?
        
        [^] # Re: WTP inempaquetable
        
        Posté par Davy Defaud le 13 juillet 2010 à 16:15. Évalué à 2.
        
        Les PDT, ce sont les PHP Development Tools, dont le but est, tu l'auras deviné, de prendre en charge le développement en PHP.
        Un autre projet, antérieur à PDT et indépendant de la fondation Eclipse, PHPEclipse, permet également de gérer des projets PHP. Son défaut est d'avoir réinventé la roue pour tout gérer par lui-même, alors que PDT, lui, s'appuie sur WTP, la Web Tools Platform qui permet déjà de gérer tout ce qui est afférent au développement web : XML, (X)HTML, CSS, JavaScript... ce qui est beaucoup plus intelligent comme approche.
        
        Il y a fort à parier que PHPEclipse disparaîtra dans un proche avenir au profit de PDT...
        
        http://www.eclipse.org/pdt/
        http://www.phpeclipse.com/
        
        Les ALL-IN-ONE, ce sont des archives au format tar compressées gzip (ou un exécutable pour Win$) contenant un Eclipse et son jeu de greffons prêts à l'emploi pour un usage donné et un système donné (Linux, MacO$, Win$ en 32 ou 64 bits). Par exemple, le ALL-IN-ONE PDT contient Eclipse Platform + PDT + WTP + plugin CVS et toutes les dépendances nécessaires.
        
        Là où les choses se gâtent, c'est lorsque tu veux ajouter des greffons supplémentaires à ton ALL-IN-ONE pour un autre usage, comme, par exemple, le support d'un autre langage.
        
        D'autre part, contrairement à l'Eclipse empaqueté par ta distro favorite, ton ALL-IN-ONE n'est pas configuré pour fonctionner en multi-utilisateur, ce qui est pourri au possible. En gros ça t'oblige à installer un Eclipse par utilisateur si tu ne cherches pas le moyen de le configurer comme le font les distros.
- [^] # Re: WTP inempaquetable
  
  Posté par Batchyx le 12 juillet 2010 à 23:17. Évalué à 5.
  
  Un jour j'ai eu besoin d'installer un plugin qui nécessitait une version plus récente d'un composant que j'avais.
  
  J'ai eu l'audace de cliquer sur 'mettre à jour mon eclipse'.
  
  Et bien, au final j'ai du finir le boulot, avec un rm -fr bien placé.
  - [^] # Re: WTP inempaquetable
    
    Posté par Donk le 12 juillet 2010 à 23:21. Évalué à 4.
    
    bien placé sur / ?
    - [^] # Re: WTP inempaquetable
      
      Posté par Batchyx le 12 juillet 2010 à 23:49. Évalué à 2.
      
      J'aurai pu, c'était dans une machine virtuelle ;)
      - [^] # Re: WTP inempaquetable
        
        Posté par dems le 13 juillet 2010 à 01:53. Évalué à 5.
        
        Mon dieu, une vm dans une vm... Tu as vraiment de la ram à ne plus savoir quoi en faire.
        
        [^] # Re: WTP inempaquetable
        
        Posté par Octabrain le 13 juillet 2010 à 01:59. Évalué à 2.
        
        http://jean-pierre-troll.blogspot.com/2009/06/les-machines-v(...)
        
        [^] # Re: WTP inempaquetable
        
        Posté par Batchyx le 14 juillet 2010 à 22:02. Évalué à 2.
        
        Oui, 1 Go, c'est bien trop gros pour moi. Donc sur le Windows 7 (au boulot, pas le choix) je met une VM Linux de 512 Mo avec un vrai gestionnaire de fenêtre, et Eclipse ;). Mais il me reste encore 100 Mo de RAM dont je ne sais pas quoi faire.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.