Débats autour de la branche 4.x d’Eclipse.

Depuis plusieurs années deux versions majeures d’Eclipse existent: la branche 3.x (historique) et la branche 4.x (précédemment baptisée e4, reposant sur de nombreux nouveaux concepts). En 2012, deux versions ont été publiées: la fondation Eclipse sort Eclipse Juno 3.8 /4.2. Dans la pratique, la version 4.2 est la version officielle, celle qui est mise en avant. Les versions packagées d’Eclipse (EPP builds) proposées sur la page des téléchargements reposent sur la version 4.2.

Pourtant cette migration à marche forcée ne satisfait pas tout le monde. De nombreuses personnes ont évoqué et documenté des problèmes de stabilité et de performance.

Mike Milinkovich, le Executive Director de la fondation Eclipse a reconnu ces problèmes en soulignant deux points [1]:

1. La migration vers une nouvelle architecture n’est jamais simple (en donnant en exemple le passage à la version 3.0). La branche 4.2 constitue l’avenir d’Eclipse.
2. La fondation a besoin de l’aide de la communauté pour améliorer la plateforme.

Le débat continue, notamment via le Bug 389175 qui réclame une double distribution (3.x et 4.x).

Il apparait qu’il y a vraiment plusieurs types d’utilisateurs de la plateforme Eclipse. De nombreuses voix s’élèvent pour dire qu’ils pensent rester sur la branche 3.x pendant un certain temps.

Qu’en pensez-vous ?
:fleche: S’agit-il de tergiversations normales lors d’un saut technologique majeur ?
:fleche: La fondation Eclipse est elle en train de rater sa migration ?
:fleche: La branche 3.x est elle aussi morte que la fondation le laisse entendre ?

[1] Juno Performance

C'est en effet le genre de choses que l'on entend toujours lors de migrations, et ce qui est vrai, c'est que ce n'est jamais une chose évidente.

Du coup je ne penses pas qu'ils soient en train de rater leur migration, même si c'est toujours mieux d'éliminer (du moins autant que possible) tous les bugs majeurs avant de mettre un truc en production, mais bon...

Pour la 3.x, ça m'étonnerait qu'elle soit morte, ils essaient juste de mettre en avant leur nouvelle version, changer les habitudes des gens.

Aujourd'hui je suis sur qu'il y a encore des personnes volontairement sous XP, pour comparer. Et je me souviens avoir attendu un bon moment pour passer à Seven, car il n'était pas aussi stable que maintenant à sa sortie.

Le problème c'est (j'ai l'impression) qu'il y a une tendance chez les gros éditeurs à nous vendre des bêta, et ça par contre c'est un véritable problème...

Les problemes de performances et de stabilite semblent etre liees a un manque de resources materielles pour mettre en place les tests necessaires. Ceci devrait se resoudre grace au debat qui a ete souleve, et au don de 20000$ fait par Google a la Fondation pour investir dans de nouvelles machines.
C'est aussi en partie du a quelques problemes "humains" de toutes parts:
* Cela fait 2 ans que l'equipe plateforme (qui developpe 4.2) encourage tous les gros acteurs du monde Eclipse a tester e4. Au final, beaucoup ont simplement ignore cela, et se plaignent maintenant (performances, CSS moches...). Le manque de feedback est AMHA la principale raison de ce souci
* L'equipe Plateforme s'est reduite a n'a pas peut-etre pas senti la necessite de s'aggrandir pour relever les challenges de e4
* Les problemes ont peut-etre ete pris un peu a la legere par l'equipe Plateforme, dont on aurait pu esperer un appel a l'aide plus fort et plus tot.

Ensuite, il apparait que les problemes de perfs ou de stabilite ne sont pas facilement reproductibles et varient beaucoup d'un environnement a l'autre. Chacun sait que ce genre de souci est dur a detecter, reproduire et reparer.

Dans le fond, l'equipe plateforme s'attendait fortement a ce genre de soucis, c'est pourquoi la version 3.8 existe en parallele de la 4.2. Et c'est assez courant sur le developpement d'un produit qu'un changement de majeure introduise des instabilites, dues aux nouvelles fonctionnalites. Je ne pense pas que ce soit la quelque chose d'alarmant.
Tout ce debat a le grand interet d'apporter enfin du feedback aux developpeurs et de mettre en place les priorites pour la prochaine version. Les gens reprochent peu de choses a Eclipse 4 (perfs, CSS par defaut moche, stabilite). Si ces quelques problemes sont repares sur la 4.3, nul doute que tout le monde oubliera la 3.x.

Hé ben du coup je comprend mieux pourquoi j'ai vomi cet ide la dernière fois que je l'ai utilisé (qui n'était pas de mon plein gré, je précise. Je n'ai jamais vraiment entendu parler d'eclipse en bien)... forcément, si la version que j'ai utilisée est en bêta, ça ne peux pas être rapide ou stable.

Pour le coup, il n'y aurait pas eu ce thread, je serai resté advitam eternam sur un avis très négatif envers eclipse. (Et c'est justifié quand je vois que l'auto-complétion se déclenchait automatiquement, ramait comme pas permis et si j'avais le malheur de faire semblant de l'ignoré, ça se finissais en crash)

Pour ce qui est des éditeurs qui sortent les versions bêta en stables, c'est sûr que c'est gênant. Dans le cas de windows, ce n'est "pas grave" puisqu'ils ont le monopoles, ils ne craignent pas trop que les gens aillent voir ailleurs.
Pour éclipse, par contre, je pense qu'ils ont du souci à se faire en voyant netbeans.
Pour info, j'avais fini par péter un câble avec eclipse et le remplacer par netbeans. La ou le 1er ne supportait que son petit format à lui pour les workspace, le 2nd gérait le sien plus celui d'eclipse en parallèle sans le moindre souci (ce qui m'a permis de l'utiliser sans encombre)
La encore, je ne suis pas un fanatique de JAVA, et au niveau de ces IDE je n'avais pas d'apriori positif. Ca a changé pour netbeans.

PS: cette réponse n'a pas vocation a troller, juste à indiquer le ressenti de quelqu'un qui teste la branche actuelle eclipse et qui utilise habituellement des IDE comme code::blocks et visual studio. Et quelqu'un qui aime les outils réactifs, ou au moins pouvoir ignorer un outil lent.

Citation:

---

Envoyé par Freem

Hé ben du coup je comprend mieux pourquoi j'ai vomi cet ide la dernière fois que je l'ai utilisé (qui n'était pas de mon plein gré, je précise. Je n'ai jamais vraiment entendu parler d'eclipse en bien)... forcément, si la version que j'ai utilisée est en bêta, ça ne peux pas être rapide ou stable.

Pour le coup, il n'y aurait pas eu ce thread, je serai resté advitam eternam sur un avis très négatif envers eclipse. (Et c'est justifié quand je vois que l'auto-complétion se déclenchait automatiquement, ramait comme pas permis et si j'avais le malheur de faire semblant de l'ignoré, ça se finissais en crash)

Pour ce qui est des éditeurs qui sortent les versions bêta en stables, c'est sûr que c'est gênant. Dans le cas de windows, ce n'est "pas grave" puisqu'ils ont le monopoles, ils ne craignent pas trop que les gens aillent voir ailleurs.
Pour éclipse, par contre, je pense qu'ils ont du souci à se faire en voyant netbeans.
Pour info, j'avais fini par péter un câble avec eclipse et le remplacer par netbeans. La ou le 1er ne supportait que son petit format à lui pour les workspace, le 2nd gérait le sien plus celui d'eclipse en parallèle sans le moindre souci (ce qui m'a permis de l'utiliser sans encombre)
La encore, je ne suis pas un fanatique de JAVA, et au niveau de ces IDE je n'avais pas d'apriori positif. Ca a changé pour netbeans.

PS: cette réponse n'a pas vocation a troller, juste à indiquer le ressenti de quelqu'un qui teste la branche actuelle eclipse et qui utilise habituellement des IDE comme code::blocks et visual studio. Et quelqu'un qui aime les outils réactifs, ou au moins pouvoir ignorer un outil lent.

---

les parts de marché sont encore faible pour netbeans
malgré tout je l'utilise les deux à titre pro et je trouve qu'eclipse devient de plus en plus lourd alors que c'est le contraire pour son homologue.

si eclipse veut pousser pour sa branche 4, ils n'ont qu'ajouter des nouvelles fonctionnalités à cet branche et corriger que les anomalie pour la branche 3

J'utilise Eclipse 3.x depuis 5 ans, accompagné de SpringIDE, du plugin Maven, et d'un plugin SCM au choix.
Certes, Eclipse est lent sur de vieilles machines. Et il peut devenir infernal avec certains plugins (AJDT est un ogre ...). Faut pas avoir peur d'avoir un IDE qui bouffe + de ram que Battlefield3 :aie: Mais dans l'ensemble il me convient bien et je suis habitué à tous les raccourcis clavier ...


J'ai donc testé la version 4.2. Elle m'a semblé plus réactive que la 3.x. Mais je l'ai viré à cause du look&feel horrible. Même en appliquant le style "classic" c'était un peu foiré...

Citation:

---

Envoyé par marc.collin

si eclipse veut pousser pour sa branche 4, ils n'ont qu'ajouter des nouvelles fonctionnalités à cet branche et corriger que les anomalie pour la branche 3

---

Il y a plein de nouvelles fonctionnalites dans la platforme 4.x, la plus visible est surement le CSS, mais la plupart sont destinees aux developpeurs de plugins. En effet, la Platform n'est pas un produit pour l'utilisateur final, ce que l'utilisateur voit, ce sont les differents plugins (JDT, WTP, m2e, Git, Findbugs...).
Tous ces plugins fonctionnent encore sur la version 3.x d'Eclipse (en plus de 4.x), donc ce n'est pas evident pour l'utilisateur de voir l'avantage de 4.x sur 3.x.
Le plan que tu proposes est celui qui a ete adopte depuis la derniere release, Juno.

Sinon, NetBeans est bien aussi, mais Eclipse se differencie par la myriades de plugins qui rend l'utilisation d'Eclipse ultra-productive, avec des integrations pour a peu pres tout ce qui existe.
Du coup Eclipse a tendance a etre rendu lourd par tous les plugins bien pratiques qu'on installe. Il pompe de la RAM, il lag, mais au final, il simplifie beaucoup les processus des developpement. NetBeans fait aussi cela, et meme en mieux avec les produits Oracle, mais il est generalement moins efficace sur toutes les autres integrations.

Citation:

---

Envoyé par bugsan

J'ai donc testé la version 4.2. Elle m'a semblé plus réactive que la 3.x. Mais je l'ai viré à cause du look&feel horrible. Même en appliquant le style "classic" c'était un peu foiré...

---

Dans ce cas, reprends 4.2 et utilise ce plugin, il fournit des biens jolis themes: https://github.com/jeeeyul/eclipse-themes/ Maintenant, mon IDE est rose et je me demande comment j'ai pu en avoir un gris avant ;)

Bonjour,

Pour ce qui en est de mon utilisation (PDT+WDT+subversive), la 4.2 me pose de gros soucis : je subit de grosses fuites mémoire et suis obligé de relancer éclipse plusieurs fois par jour, je pense retourner a la branche 3.X, le temps que ceci évolue.

Les fuites sont surement dues a leur couche de compatibilité pour les plugins écrits pour éclipse 3.X, j'ai en parallèle l'impression que zend commence a lâcher PDT, donc ce n'es pas de bonne augure pour les dev. PHP...

Effectivement pas évident de faire la différence entre Eclipse IDE et Eclipse Platforme...

Ce qui me semble étrange, c'est le nombre de personnes qui semblent être sur la dernière version sortie. Dans ma boite pour l'IDE on travaille plutôt sur les version SR2 n-1 ou n-2...
Dans tous les cas on a une "distribution" perso. Personne ne va sur eclipse.org pour télécharger une version d'Eclipse.

Pour nos logiciels basés sur la plateforme on est aussi plutôt conservateur... En même temps nos logiciels n'ont plus grand chose à voir avec l'IDE... Ils ne sont pas destiné à s'y intégrer (ce sont des applications autonomes) et je ne suis pas certain qu'on ait besoin des nouveautés.

En fait je pense qu'on passera vers mi 2013 à la 3.8 SR2. Dans deux ans on pourra toujours se poser la question d'une migration vers 4.3 SR2 ou non.


En fait, pour la partie IDE on ne doit pas vraiment être représentatif... Quand on voit le nombre de personnes qui ont installé la 4.2 et qui s'en plaignent.

Peut être que le vrai problème est pour les néophyte...

.

Citation:

---

Envoyé par jmini

Ce qui me semble étrange, c'est le nombre de personnes qui semblent être sur la dernière version sortie. Dans ma boite pour l'IDE on travaille plutôt sur les version SR2 n-1 ou n-2...
Dans tous les cas on a une "distribution" perso. Personne ne va sur eclipse.org pour télécharger une version d'Eclipse.

---

On peut s'interroger sur le reel gain de cette approache. Les projets evoluent vite, s'interdire les mises a jour pendant 9 mois ca peut etre contre-productif. EGit est le meilleur exemple en la matiere actuellement.
Ensuite, je comprends parfaitement que si vous utilisez un environnement bien perso et bien tricky, avec des extensions internes ou ce genre de choses, un phase de validation peut etre utile. Mais elle ce qu'elle vaut l'attente ?

Citation:

---

Pour nos logiciels basés sur la plateforme on est aussi plutôt conservateur... En même temps nos logiciels n'ont plus grand chose à voir avec l'IDE... Ils ne sont pas destiné à s'y intégrer (ce sont des applications autonomes) et je ne suis pas certain qu'on ait besoin des nouveautés.

---

Goute un peu a l'injection de dependances (et des services), et tu te diras que tu ne refeeras plus jamais de developpement RCP sans ca ;)
Le CSS ca le fait pas mal aussi pour brander son appli RCP.
Le modeled workbench simplifie beaucoup la vie, surtout au demarrage de nouvelles applis.
Il y a pas mal de features qui valent le coup dans Eclipse 4 IMHO.

Citation:

---

En fait je pense qu'on passera vers mi 2013 à la 3.8 SR2. Dans deux ans on pourra toujours se poser la question d'une migration vers 4.3 SR2 ou non.

---

D'ici 2013, les problemes de qualites de la 4.x seront surement fixes, ce serait dommage de se priver des ameliorations, qui sont plutot orientees a faire gagner de la productivite lorsqu'on ecrit des plugins ou des applis RCP.
Retarder la migration constitue une prise de risque.

Citation:

---

En fait, pour la partie IDE on ne doit pas vraiment être représentatif... Quand on voit le nombre de personnes qui ont installé la 4.2 et qui s'en plaignent.

---

Peu de boites ont ce genre de configs toutes faites. D'apres mon experience (4 employeurs differents), tu arrives dans la boite et il y a une page de wiki qui te dit quoi installer dans ton environnement. La partie Eclipse recommande un package et tels plugins, tu le fais et voila.
A noter que souvent la liste des plugins et un peu arbitraire et pas forcement bien faite: elle oublie souvent Findbugs et PMD, neglige les integration avec Jacoco & Sonar, te force a utiliser Subclipse ou lieu de Subversive (les 2 ont la meme qualite depusi 1 an et demi...), ne parle pas des connecteurs Mylyn et m2e... Elle est en generale vieille d'un an...
Bref, la plupart du temps le developpeur sait s'installer un environnement plus efficace que celui qu'on lui recommande. Dans le fond, c'est bien de le guider, mais mettre en place un bon environnment fait partie du metier de developpeur, et il le fait generalement mieux qu'un gars qui est la davantage pour superviser que pour coder.

Citation:

---

Peut être que le vrai problème est pour les néophyte....

---

Les neophytes ont moins d'avis critiques. S'ils installent Eclipse pour la 1ere fois, ils ne vont pas dire "c'etait mieux avant" comme on l'entend tout le temps.
Les plaintes viennent souvent de personnes experimentees qui travaillent chez des grosses boites qui esperaient beaucoup d'Eclipse 4 et qui sont un peu decus de la qualite de cette premiere version publique.

Citation:

---

Envoyé par Mickael_Istria

Bref, la plupart du temps le developpeur sait s'installer un environnement plus efficace que celui qu'on lui recommande. Dans le fond, c'est bien de le guider, mais mettre en place un bon environnment fait partie du metier de developpeur, et il le fait generalement mieux qu'un gars qui est la davantage pour superviser que pour coder.

---

Oui en même temps c'est pas exactement comme ça que ça se passe: quelques codeurs ont en plus la responsabilité de choisir/tester la bonne combinaison d'outils.

C'est fait une fois, pour toute la boite, avec la possibilité pour certains projets qui veulent autre chose de se faire leur propre sous-configuration (ou de rester sur l'ancienne pour des raisons de compatibilité).

À vrai dire je ne comprends pas la remarque "[ça] fait partie du metier de developpeur". Il faut savoir le faire c'est certain, mais je suis bien content de ne pas avoir à me demander chaque semaine si par hasard telle maj du plugin vaut le coup ou est incompatible avec d'autres choses (pendant longtemps il y avait un pb avec un plugin Team Provider SVN - je ne sais plus lequel).

Citation:

---

Envoyé par Mickael_Istria

On peut s'interroger sur le reel gain de cette approache. Les projets evoluent vite, s'interdire les mises a jour pendant 9 mois ca peut etre contre-productif. EGit est le meilleur exemple en la matiere actuellement.

---

Je ne saurais pas dire quelle version de EGit on a actuellement (pas l'IDE sous la main), mais il ne me semble pas que EGit requiert la version 4.2 d'Eclipse. Évidemment les plugins qui vont bien sont mis à jours. L'autre bon exemple est le plugin maven (m2e => les versions récentes sont plus efficaces).

Citation:

---

Envoyé par Mickael_Istria

Ensuite, je comprends parfaitement que si vous utilisez un environnement bien perso et bien tricky, avec des extensions internes ou ce genre de choses, un phase de validation peut etre utile. Mais elle ce qu'elle vaut l'attente ?

---

Je ne crois pas qu'on ait des choses si spécifiques... Mais il y a aussi pas mal de plugins qui sont juste inconnu des développeurs Eclipse (par exemple "Compare to > Clipboard", ou un autre qu'on a pour gérer la licence et les headers des fichiers). Un jour sur une installation fraiche d'Eclipse, je me suis rendu compte de tout ce qui n'était pas par défaut (Ca ma rappelé quand j'étais étudiant).

Un composant perso qu'on a c'est un mécanisme pour mettre à jour Eclipse... Histoire que les modifs faites à la setup d'entreprise (ou de projet) soient propagées à tout le monde. (ça se fait le matin au démarrage d'Eclipse => un petit peu pénible, mais ça laisse le temps pour lire ses mails ou un café).

Je crois que le composant de mise à jour pourrait être largement amélioré. Le bousin existait avant p2 et autres nouveautés dans le domaine... C'est presque du Legacy à ce niveau-là. Je n'ai jamais trop creusé, mais on pourrait arriver au même résultat avec un outil comme yoxos.

Forcer les devs à utiliser un package Eclipse préconfiguré c'est réactionnaire. C'est croire encore que les devs sont des ouvriers irresponsables :mouarf:

Un commiter Eclipse, est-ce qu'on lui fournit un Eclipse tout fait, ou bien est-ce qu'on lui fait confiance ?

Citation:

---

Envoyé par bugsan

Forcer les devs à utiliser un package Eclipse préconfiguré c'est réactionnaire. C'est croire encore que les devs sont des ouvriers irresponsables

---

Réactionnaire, rien que ça... ? Tu crois vraiment que les services informatiques ont ce genre d'idées en tête pour imposer cela ? Tu ne te dis pas plutôt que ça à tout bêtement l'intérêt d'avoir un environnement projet homogène, évitant ainsi les problèmes d'incompatibilités par exemple, ou de perte de temps à tout installer soi-même ?

Le sujet concerne la branche 4.x d'Eclipse, donc merci d'éviter de dévier de celui-ci.

Citation:

---

Envoyé par bugsan

Forcer les devs à utiliser un package Eclipse préconfiguré c'est réactionnaire. C'est croire encore que les devs sont des ouvriers irresponsables :mouarf:

---

A vrai dire je ne me suis jamais demandé si j'étais "forcé"... Je ne crois pas... C'est juste que c'est beaucoup plus simple d'avoir le même IDE (au version des plugin près) dans une équipe.

D'ailleurs on a pas vraiment de services informatiques... Quelques personnes s'en occupent... Ca ne consitute pas vraiment un service.

Citation:

---

Envoyé par Laurent.B

Le sujet concerne la branche 4.x d'Eclipse, donc merci d'éviter de dévier de celui-ci.

---

Sinon je me rends compte que je n'ai pas gardé les URL des post de blog importants. Voici ma petite revue de presse:
* Juno Performance: les commentaires sont vraiment intéréssants.

* Something is really broken with Eclipse foundation (Un des sujet qui a mis le feu au poudre)

* The Safe Road (La demande pour une double release)

* Ignorantia iuris nocet: revient sur le fait que malgré les appels à contribution rien ne s'est réellement passé. Beaucoup de personnes considèrent la plateforme Eclipse comme acquise. Pourtant il n'en est rien.

Il faut baisser la barrière d'entrée pour les commiteurs intéréssé par la branche 4 d'Eclipse. (Un bug a été ouvert pour cela).

* So Long, and Thanks for All the Fish: IBM s'est retiré du soutient massif à la plateforme Eclipse, un nouveau modèle doit émerger pour soutenir la plateforme.

Citation:

---

Envoyé par jmini

Voici ma petite revue de presse

---

Ca continue:
* Eclipse 4 – Uh Oh! Trouble’s brewin?