Eclipse Juno est disponible

La fondation Eclipse sort Eclipse Juno 3.8 /4.2

La fondation Eclipse vient de sortir la version Juno d'Eclipse.

Une nouvelle version d'Eclipse est disponible. Elle porte le nom de Juno. Cette version est en fait une double version, puisque nous avons droit à la fois à la version 3.8 et à la version 4.2.

Il faut savoir que la version 3.8 est la dernière "version" pour Eclipse 3.XX. Des versions de maintenance sont prévues pour la 3.8, mais aucune version majeure supérieure n'est prévue dans les 3.XX.

Cela tient d'une volonté de la fondation Eclipse de basculer majoritairement sur les versions 4.XX. La version 4 (précédemment baptisée e4) d'Eclipse est en développement depuis 4 ans et constitue la majeure partie de cette release.

Des informations supplémentaires sur les nouveautés de cette version sont disponibles à cette adresse : notes pour la version 3.8, notes pour la version 4.2.

Pour télécharger cette nouvelle version rendez-vous sur la page de téléchargement d'Eclipse : http://www.eclipse.org/downloads/

D'un point de vue esthétique, cette version inclut :

• une barre de recherche rapide ;
• un nouveau look pour le workbench ;
• la possibilité de mélanger les vues et les éditeurs (plus de zone réservée aux seuls éditeurs) ;
• la possibilité de détacher les éditeurs.

De plus profonds changements ont été apportés au modèle de programmation. Le workbench est maintenant représenté comme un modèle EMF et est rendu dynamiquement.

Les composants graphiques peuvent maintenant être customisés à l'aide d'un moteur CSS.

La plateforme supporte maintenant l'injection de dépendances.

L'incubateur e4 comporte quelques outils absolument intéressants (comme un éditeur de modèle qui permet le changement "en live" de l'interface graphique ainsi qu'un CSS-Spy pour examiner les propriétés CSS des éléments).

Enfin, cette nouvelle version inclut une couche de compatibilité qui permet de supporter les versions 3.XX sur cette plateforme.

Dans les nouveautés, nous pouvons également citer :

• le plug-in de recommandation de code : ce plug-in va indiquer au développeur, dans l'assistant de contenu, les méthodes les plus probables à implémenter, des templates de codes le plus souvent utilisés (ex. pour la création d'un Button, on lui donne un texte, un layout, des styles puis une action), des recommandations sur les méthodes les plus surchargées, une documentation étendue, une complétion plus complexe pour les mots contenus dans la méthode (ex. : "background" pour "drawBackground()" ou "getBackgroundImage()" ;
• XText/Xtend (support du débogage intégré des DSL) ;
• Orion ;
• des améliorations pour JDT notamment : au niveau du support de Java 7, des améliorations du moteur d'évaluation (pour les breakpoints conditionnels), de l'analyse basée sur les annotations... ;
• amélioration du support de GiT ;
• Virgo : un projet qui embarque un noyau Nano pour créer de petites applications web basées sur OSGi ;
• Koneki : projet qui fournit un IDE pour Lua (un langage de script) ;
• amélioration RAP ;
• utilisation des features pour lancer des configurations et des cibles ;
• Mylyn Intent.

La liste des nouveautés se trouve ici : http://help.eclipse.org/juno/index.j..._whatsnew.html


Et vous ?
:fleche: Que pensez-vous de cette nouvelle version ? Et de ces nouvelles fonctionnalités ?
:fleche: Avez-vous déjà essayé Eclipse 3.8 ? Ou Eclipse 4.2 ?
:fleche: En tant que développeur RCP, êtes-vous prêt à changer votre modèle de programmation Eclipse ?

Source: PlanetEclipse

C'est toujours très impressionnant cette sortie simultanée. Bravo pour votre synthèse.

De ce que j'ai pu essayer, la branche 4.x est finalement plutôt au niveau (même si de très nombreux projets utilisent le layer de compatibilité vers 3.x).

Pour moi, la branche 4.x apporte beaucoup de chose moderne a la plateforme applicative d'Eclipse. Ils ont un peu passé en force la branche 4.x en fondant l'IDE Eclipse dessus et en faisant de la version 4.2 d'Eclipse la version officielle (pour mémoire l'année dernière une version 4.1 avait été publiée en même temps que la 3.7, mais la version 3.7 est la version principale).

Je pense que cette nouvelle plateforme (car il faut bien parlé de nouvelle - ce n'est pas une simple mise à jour) est très intéressante pour les nouveau projets. Ils pourront bénéficier de choses plus uniforme, d'injection de dépendance, et de beaucoup d'autres choses qui font que cela a l'air génial.

Maintenant pour les grosses applications en 3.x, je pense qu'elle ne vont pas faire de migration dans l'immédiat. Le compatibility layer est principalement centré sur l'IDE Eclipse. Ce n'est même pas certain que cela marche pour une application RCP simple. Quand on imagine le coût de migration d'une grosse application RCP, je me dis que la version 3.x est loin d'être morte (quoi qu'en dise la fondation).

Sur Eclipse 4, j'avais bien aimé lire les Retours Eclipse Con 2012 d'Olivier Prouvost (la partie intitulée Eclipse 4). Au moins c'est plus pondéré et réaliste que celui des commiters Eclipse (qui sont à fond sur Eclipse 4).

Citation:

---

Envoyé par jmini

Maintenant pour les grosses applications en 3.x, je pense qu'elle ne vont pas faire de migration dans l'immédiat. Le compatibility layer est principalement centré sur l'IDE Eclipse. Ce n'est même pas certain que cela marche pour une application RCP simple. Quand on imagine le coût de migration d'une grosse application RCP, je me dis que la version 3.x est loin d'être morte (quoi qu'en dise la fondation).

---

Il est très facile de tester: la compatibility layer s'active juste en ayant les bons bundles dans ton application RCP.
Pour essayer:
* Passe ta target-platform vers un Eclipse 4.2
* Ajoute les bundles ou features nécessaires à ton .product pour activer la compatibility layer d'Eclipse 4 : http://www.vogella.com/articles/Ecli...r/article.html
* Lance ton application et vois si tout marche bien

Essayer coute très peu de temps. Je recommanderai de faire ce test à tous ASAP, sinon, vous vous créez de la dette technique, qui coutera plus cher plus tard. Aussi si tout marche, le gain de productivité apporte par les améliorations d'Eclipse 4 est censé rapidement amortir les efforts de migration.
Pour ce qui est de "compatibility layer très axée sur l'IDE", le release train Juno a imposé à tous ces projets d'être testés sur Eclipse 4, et donc la compatibility layer (car aucun projet à part la platforme n'utilise pour l'instant Eclipse 4). Donc avec les 60 et quelques projets de Juno, on a quand même une bonne couverture positive de la compatibility layer. Les risques de problèmes sont assez faibles. S'il reste des problèmes, mieux vaut pour tous (et surtout les développeurs d'applications RCP) qu'ils soient détectés et fixés assez vite, sous peine d'être bloqué sur Eclipse 3 pendant longtemps.
Et encore une fois, ça ne coute quasiment rien d'essayer ;)

Citation:

---

Envoyé par Mickael_Istria

Essayer coute tres peu de temps. Je recommanderai de faire ce test a tous ASAP, sinon, vous vous creez de la dette technique, qui coutera plus cher plus tard. Aussi si tout marche, le gain de productivite apporte par les ameliorations d'Eclipse 4 est cense rapidement amortir les efforts de migration.

---

C'est pas du tout aussi évident. Un bon aperçu sur les possibilités est donné ici dans cet article: Migrating from Eclipse 3.x to Eclipse 4 (e4).

Ensuite je ne sais pas du tout quelle est la taille de l'application, mais ce genre de modification nécessite de tout retester... Pas certain qu'aujourd'hui le jeu en vaille la chandelle.
Ensuite, visuellement la migration n'est pas invisible. Voir à ce sujet le coup de gueule d'Andrei Loskutov. Là il parle de l'IDE, mais le même genre de réaction peut avoir lieu dans le cas d'une application RCP.

La où je travaille on est plutôt très conservateurs... On attend la SR2 pour faire une migration... J'imagine qu'on ira plutôt vers la 3.8 dans un premier temps. Et encore c'est une application dans laquelle on ne se sert pas beaucoup du workbench.

Enfin bon, je salue le travail de la 4.2 qui est une très bonne chose. Maintenant de là à dire à tout le monde que la migration "c'est facile, tout marche, il n'y a rien à faire"... C'est pas ma vision.

Citation:

---

Envoyé par jmini

C'est pas du tout aussi évident. Un bon aperçu sur les possibilités est donné ici dans cet article: Migrating from Eclipse 3.x to Eclipse 4 (e4).

---

Si tu as un application qui tourne en 3.7, alors la compatibility layer te la fait tourner sur une 4.2. C'est une première étape nécessaire, même si tu attends 2 ans pour la faire. Elle correspond a l'option 1 de l'article de blog, se teste très peu de temps.
En gros, ce que j'annonce être facile, c'est de tout migrer sur la compatibiliy layer et de continuer à écrire du code avec les API de la 3.x. A titre d'exemple, on en est là pour JBoss Developer Studio. On a changé et on identifie les difficultés.

Pour ce qui est de migrer au modèle de développement e4, c'est une autre étape, qui est en effet plus délicate, a commencer par la migration de l'application vers un modèle d'application. Est-ce que "le jeu en vaut la chandelle"? Seul toi peut juger, ca dépend beaucoup de ton application, de tes contraintes et de ta roadmap...

Citation:

---

Ensuite je ne sais pas du tout quel est la taille de l'application, mais ce genre de modification nécessite de tout retester... Pas certain qu'aujourd'hui le jeu en vaille la chandelle.

---

Il faudra le faire à un moment ou l'autre, et le prix des tests grossira avec ton application. Donc au plus tôt tu fais la transition, au moins cher il te coute.
Malheureusement, il n'y a pas de metrics sur le gain de productivité, mais il semble clair qu'au plus tôt tu as fais le changement, au plus tôt les développeurs deviennent plus productifs, et donc au plus tu y gagnes.
Après, je comprends tout a fait qu'il y a souvent d'autres choses plus fonctionnelles qui valent plus le coup dans une roadmap.

Citation:

---

Ensuite, visuellement la migration n'est pas invisible. Voir à ce sujet le coup de gueule d'Andrei Loskutov. Là il parle de l'IDE, mais le même genre de réaction peut avoir lieu dans le cas d'une application RCP.

---

D'accord.

Citation:

---

La où je travaille on est plutôt très conservateur... On attend la SR2 pour faire une migration... J'imagine qu'on ira plutôt vers la 3.8 dans un premier temps. Et encore c'est une application dans laquelle on ne se sert pas beaucoup du workbench.

---

Je peux comprendre le cote conservateur. Mais commencer la migration à partir de la 4.2 SR2 alors que la première étape prend 1 heure sans rien changer à la manière de développer, c'est augmenter les risques de mauvaises surprises plus tard.
Un autre risque que je sens, c'est pour les projets Eclipse existant: vont-ils garder la compatibilité 3.x longtemps ? Là c'est au cas par cas, en fonction des gouts des intervenants j'imagine. A titre d'exemple, je pense que quand JBoss Developer Studio aura migré sur le modèle e4, les intervenants JBoss sur les projets Eclipse auront tendance à pousser du e4 pour récupérer le ROI de l'effort de migration. J'imagine que tout le monde est sur la même ligne, donc autant anticiper un peu.

Citation:

---

Maintenant de là à dire à tout le monde que la migration "c'est facile, tout marche, il n'y a rien à faire"... C'est pas ma vision.

---

Tout n'est pas facile, mais c'est facile et non risqué de faire le premier pas en avant. Pas dit que ça satisfasse tout le monde, mais ça aide vraiment à se faire une première idée des risques et du coût.

Je crois qu'on est plutôt d'accord...

Je ne connais pas vraiment JBoss Developer Studio, mais il me semble que c'est très proche de l'IDE Eclipse (JDT, et plein d'autre projets...). A mon avis c'est très différent pour une application pure RCP (qui n'utilise aucun des éditeurs de l'IDE...).

Bonjour,

Je n'avais pas testé e4 jusqu'à hier et force est de constater qu'au niveau IHM, je pense la même chose qu'Andrei Loskutov.
Je me suis demandé ce qui pouvait avoir poussé à un tel résultat. Franchement, c'est dommage d'avoir touché à l'IHM si c'est pour faire ça.

Ce qui m'agace vraiment ce sont ces marges qui ne servent à rien... Je me demande d'où ça vient. Est-ce le même résultat sur tous les OS ?
On peut basculer pour revenir dans la présentation précédente en mettant Classic dans le menu Preferences > General > Appearance. Il faut d'ailleurs redémarrer (ce qui n'est même pas expliqué) pour que ça prenne effet. Par contre, moi qui n'aime pas la perte d'espace inutile, comme les bords en forme de vague sur les onglets, hé bien en mode Classic, il n'y a pas l'option pour remettre les onglet à l'ancienne. Donc, c'est moyen.
De plus, les icônes de la barre d'outil n'ont pas été retravaillés en fonction de la couleur de fond (en tous les cas sur certains c'est flagrant), ce qui les rend encore plus moches.

Bon, ce n'est que le côté visuel, ça n'est donc pas très grave. Cela dit, en ayant connu Eclipse 3, on peut être déçu et commencer à avoir des préjugés sur le reste (probablement à tort).

Il est sûrement plus intéressant de savoir ce que cette nouvelle plateforme permet mais pour l'instant je ne m'y suis pas encore intéressé...

Citation:

---

Envoyé par Laurent.B

On peut basculer pour revenir dans la présentation précédente en mettant Classic dans le menu Preferences > General > Appearance. Il faut d'ailleurs redémarrer (ce qui n'est même pas expliqué) pour que ça prenne effet.

---

Un bug est ouvert pour l'avertissement de l'obligation redémarrer:Bug 362522

A mon avis sur la partie UI, devant le tollé général, ils vont essayer de changer certaines choses.

Citation:

---

Envoyé par jmini

A mon avis sur la partie UI, devant le tollé général, ils vont essayer de changer certaines choses.

---

Ouvrez des bugs pour partager vos idees d'ameliorations, sinon ils ne devineront pas forcement quoi ameliorer.