Discussion :

[Mickael Baron]

L’environnement de développement open source Eclipse évolue pour répondre aux besoins des développeurs. Eclipse 4.4 est disponible en téléchargement. Baptisé Luna (déesse de la Lune dans la mythologie romaine), l’EDI promet d’illuminer le quotidien des développeurs avec son lot de nouveautés.

Le fait marquant de cette nouvelle version est, sans aucun doute, le support natif de Java 8. En effet, même si Eclipse Kepler supportait Java 8 dès sa sortie, il fallait lui adjoindre un patch afin que les développeurs Java puissent profiter des Lambdas.

Des informations supplémentaires sur les nouveautés de cette version sont disponibles à cette adresse : https://projects.eclipse.org/releases/luna. Eclipse Luna se compose de 76 projets, pour un total d'environ 10 millions de nouvelles lignes de code. 339 contributeurs à travers le monde ont participé à cet effort. Huit projets ont rejoint le « simulatenous release train » : EMF Client Platform, EMF Store, Sirius, BPMN2 et BPMN2 Modeler Project, Paho QVTd et XWT. L'ensemble des projets disponibles dans cette version est disponible à cette adresse : https://projects.eclipse.org/releases/luna/details

Sans être exhaustifs, les principales nouveautés autres que le support de Java 8 sont :

• le projet Sirius, qui permet de construire de manière simple et totalement nouvelle des éditeurs, basé sur le framework de méta-modélisation EMF et sa couche graphique spécifique GMF. Avec Eclipse Sirus, le développement d'éditeurs devient déclaratif ;
  
  
  
• un nouveau thème graphique "sombre" très proche de ce qui a été proposé par les dernières versions de l'environnement de développement IntelliJ ;
  
  
  

• la possibilité de créer des vues de type "E4" depuis un plugin. La nouvelle API E4 ne sera donc plus réservée aux applications Eclipse RCP ;
  
  
  
• un client de type terminal sous Windows, Linux et MAC via le projet TCF ;
  
  
  

• une amélioration sensible du Workbench, qui permet notamment de pouvoir séparer un même éditeur en 2 parties, soit horizontalement, soit verticalement ;
• l'éditeur graphique d'EMF (Editor Diagram) a été entièrement rebâti en se basant sur le projet Sirus ;
• une amélioration de la bibliothèque EGIT, l'implémentation Java de GIT. L'outil graphique de fusion a également été amélioré.

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

Cette courte vidéo revient sur les principales nouveautés :

Et vous ?

• Que pensez-vous de cette nouvelle version ? Et de ces nouvelles fonctionnalités ?
• Avez-vous déjà essayé cette nouvelle version ?
• Allez-vous migrer ?

[Shuty]

Géniale l'intégration d'un terminal sous éclipse ! C'est bien pratique pour modifier les droits et reloader les config tomcat.

10 millions de nouvelles lignes de code. 339 contributeurs

Une minute de silence pour tous ces courageux qui ont offerts de leurs temps.

[Mickael_Istria]

Une minute de silence pour tous ces courageux qui ont offerts de leurs temps.

T'inquietes, la grande majorite des contributeurs le font dans un cadre professionnel, donc le temps leur est paye, donc ils ne meritent pas vraiment tant d'honneur

[Shuty]

T'inquietes, la grande majorite des contributeurs le font dans un cadre professionnel, donc le temps leur est paye, donc ils ne meritent pas vraiment tant d'honneur

Bon, et bien crachont leurs dessus alors

[Traroth2]

J'aimerais savoir à quel moment les responsables d'Eclipse ont prévu de hisser cet IDE à la hauteur d'IntelliJ. J'ai utilisé Eclipse pendant presque 10 ans, et ça marche plutôt bien, mais maintenant que j'ai essayé IntelliJ, j'ai du mal à me contenter d'Eclipse, je dois dire. Quelle est la différence ? IntelliJ simplifie la vie du développeur. Si vous l'installez et que, par exemple, un Maven est déjà installé sur votre poste, il va vous demander si vous voulez importer sa configuration, avec son repository, et le configurer comme outil Maven par défaut. Il est capable de lire les projets NetBeans et Eclipse. Bref, il anticipe les besoins du développeur, et franchement, on s'y habitue...

C'est pour ça que je me demande pourquoi Eclipse et NetBeans ne cherchent pas à atteindre le même niveau de fonctionnalité et d'ergonomie...

[Mickael_Istria]

J'aimerais savoir à quel moment les responsables d'Eclipse ont prévu de hisser cet IDE à la hauteur d'IntelliJ.

Il n'y a pas de responsable de l'IDE Eclipse, seulement des contributeurs.

J'ai utilisé Eclipse pendant presque 10 ans, et ça marche plutôt bien, mais maintenant que j'ai essayé IntelliJ, j'ai du mal à me contenter d'Eclipse, je dois dire. Quelle est la différence ? IntelliJ simplifie la vie du développeur. Si vous l'installez et que, par exemple, un Maven est déjà installé sur votre poste, il va vous demander si vous voulez importer sa configuration, avec son repository, et le configurer comme outil Maven par défaut. Il est capable de lire les projets NetBeans et Eclipse. Bref, il anticipe les besoins du développeur, et franchement, on s'y habitue...

C'est pour ça que je me demande pourquoi Eclipse et NetBeans ne cherchent pas à atteindre le même niveau de fonctionnalité et d'ergonomie...

Ce genre de suggestions pour ameliorer Eclipse IDE est plus que bienvenu sur le bugtracker d'Eclipse: bugs.eclipse.org.

[Traroth2]

Il n'y a pas de responsable de l'IDE Eclipse, seulement des contributeurs.

Dans ce cas, ça doit être le premier projet open-source un peu important sans gouvernance que je connaisse.

Ce n'est pas parce qu'un projet est open-source que n'importe qui peut commiter n'importe quoi...

Ce genre de suggestions pour ameliorer Eclipse IDE est plus que bienvenu sur le bugtracker d'Eclipse: bugs.eclipse.org.

Je ne contribue pas à Eclipse. Et d'expérience, la plupart des communautés sont assez réticentes aux gens qui viennent leur dire quoi faire sans participer. Comment les blâmer, d'ailleurs ? Personne n'aime recevoir des lettres au Père Noël. Ce n'est peut-être pas la position la plus constructive, mais c'est humain.

Et puis, ils ont des yeux dans la tête, non ? Je veux dire, les avantages d'IntelliJ sur Eclipse sont abondamment documentés ailleurs qu'ici, après tout...

https://www.google.fr/#q=eclipse+intellij+comparison

[atha2]

Je ne contribue pas à Eclipse. Et d'expérience, la plupart des communautés sont assez réticentes aux gens qui viennent leur dire quoi faire sans participer. Comment les blâmer, d'ailleurs ? Personne n'aime recevoir des lettres au Père Noël. Ce n'est peut-être pas la position la plus constructive, mais c'est humain.

J'ai du mal à croire qu'un suggestion d'amélioration d'une personne externe soit mal vue. N'y a-t-il juste pas un problème de forme ? Il est évident que "j'ai besoin de ça" ne passe pas aussi bien que "il pourrait être d'intéressant d'inclure ça, beaucoup de dev ont ce besoin".
Enfin, c'est peut-être ce qui arrive quand la plupart des membres sont payés par leur entreprise pour réaliser des objectifs précis sur ce projet.

[Mickael_Istria]

Dans ce cas, ça doit être le premier projet open-source un peu important sans gouvernance que je connaisse.

Il y a de la gouvernance, mais il n'y a personne qui a le doit d'imposer des roadmaps. Chacun est libre de contribuer ce qu'il veut ou pas, c'est aux committers de decider si ca vaut le coup de l'integrer ou pas. Les committers sont responsables de faire les reviews, pas de dire aux contributeurs "code-ci" ou "code-ca".
La Fondation assure une gouvernance de la communaute et anime l'ecosysteme.

Je ne contribue pas à Eclipse.

Et bien en fait detrompe-toi. Avec ce genre de commentaire, tu contribues en fait un peu a Eclipse

Et d'expérience, la plupart des communautés sont assez réticentes aux gens qui viennent leur dire quoi faire sans participer.

La je ne suis pas d'accord du tout. En tout cas, sur les projets dans lesquels je suis impliques, les suggestions d'ameliorations ont une grande valeur. Par contre, il faut faire attention a comment on redige ca. Il ne faut pas donner des lecons, mais plutot suggerer, raconter ses use-cases, et conclure par des idees concretes.
Si par exemple tu ouvres un bug a n'importe quel projet pour expliquer que selon toi un bouton est mal place ce qui diminue l'ergonomie, ca fera reflechir, et si ton idee fait l'unanimite, il en resultera un changement.

Comment les blâmer, d'ailleurs ? Personne n'aime recevoir des lettres au Père Noël. Ce n'est peut-être pas la position la plus constructive, mais c'est humain. Et puis, ils ont des yeux dans la tête, non ? Je veux dire, les avantages d'IntelliJ sur Eclipse sont abondamment documentés ailleurs qu'ici, après tout...

Et bien sache que certaines personnes aiment recevoir des lettres au pere noel. Les committers ont souvent la tete dans le guidon, a travailler sur des nouvelles features importantes et n'ont pas forcement l'occasion de prendre du recul. Ce genre de requete venant des utilisateurs sont rafraichissantes, les idees suggerees par les utilisateurs sont souvent bien loin des idees que se font les committers de leur projet.

Bref, c'est comme tout, si tu veux que les choses s'ameliorent, mieux vaut s'impliquer un peu. Ouvrir des bugs en tant qu'utilisateur constitue un tres bon premier pas.

[Traroth2]

Il y a de la gouvernance, mais il n'y a personne qui a le doit d'imposer des roadmaps. Chacun est libre de contribuer ce qu'il veut ou pas, c'est aux committers de decider si ca vaut le coup de l'integrer ou pas. Les committers sont responsables de faire les reviews, pas de dire aux contributeurs "code-ci" ou "code-ca".
La Fondation assure une gouvernance de la communaute et anime l'ecosysteme.

Ben ça doit pour être ça, alors. Parce que dans la plupart des projets, quand on se lance dans une nouvelle version de dev, on discute d'abord de ce qu'on va mettre dedans, c'est pas chacun qui part sur ce qu'il veut n'importe comment. Par exemple, si tu vas voir sur le groupe de discussion de Vert.x (un autre projet d'Eclipse Foundation), tu verras qu'en ce moment, ça parle de ce qu'ils veulent mettre dans la version 3.0.

La je ne suis pas d'accord du tout. En tout cas, sur les projets dans lesquels je suis impliques, les suggestions d'ameliorations ont une grande valeur. Par contre, il faut faire attention a comment on redige ca. Il ne faut pas donner des lecons, mais plutot suggerer, raconter ses use-cases, et conclure par des idees concretes.
Si par exemple tu ouvres un bug a n'importe quel projet pour expliquer que selon toi un bouton est mal place ce qui diminue l'ergonomie, ca fera reflechir, et si ton idee fait l'unanimite, il en resultera un changement.

Ben ça doit pour être ça, alors. Parce que dans la plupart des projets, quand on se lance dans une nouvelle version de dev, on discute d'abord de ce qu'on va mettre dedans, c'est pas chacun qui part sur ce qu'il veut n'importe comment. Par exemple, si tu vas voir sur le groupe de discussion de Vert.x (un autre projet d'Eclipse Foundation), tu verras qu'en ce moment, ça parle de ce qu'ils veulent mettre dans la version 3.0.

La je ne suis pas d'accord du tout. En tout cas, sur les projets dans lesquels je suis impliques, les suggestions d'ameliorations ont une grande valeur. Par contre, il faut faire attention a comment on redige ca. Il ne faut pas donner des lecons, mais plutot suggerer, raconter ses use-cases, et conclure par des idees concretes.
Si par exemple tu ouvres un bug a n'importe quel projet pour expliquer que selon toi un bouton est mal place ce qui diminue l'ergonomie, ca fera reflechir, et si ton idee fait l'unanimite, il en resultera un changement.

Oui, ça dépend des gens, dirons-nous. En l'occurrence, vue l'ampleur de ce qu'il faudrait changer, je ne vois pas très bien comment ça pourrait être bien pris de la part d'un outsider. Par exemple, dégager complètement le .project et tout faire avec du pom.xml, c'est le genre de proposition qui risque de changer à peu près tout dans Eclipse. J'ai du mal à imaginer que ça puisse bien passer. Parce que l'intégration Maven, c'est juste une horreur sans nom, quoi. Déjà, c'est toujours une pièce rapportée, c'est à dire un plugin optionnel. Ensuite, on peut toujours ajouter des bibliothèques directement dans le projet Eclipse (même si on a créé directement un projet Maven). Et on peut continuer. Parfois ça build en ligne de commande mais pas dans Eclipse, parfois l'inverse. Il y a 2 endroits où spécifier le config.xml, ce qui créé un joyeux merdier, mais on peut quand même indiquer un repo local ailleurs que ce qu'on trouve dans config.xml, etc. La réalité, c'est qu'on ne peut pas développer facilement en utilisant Maven sous Eclipse. Et ça, en 2014, ça commence à devenir franchement éliminatoire.

De ce point de vue, IntelliJ détecte à peu près tout : outils de versioning, de build (pas que Maven, mais aussi Gradle, par exemple), les serveurs installés, genre Tomcat ou Glassfish, pour lesquels des confs sont ajoutés pour pouvoir déployer directement dessus, et bien sûr les piloter et debugger avec. Tout ça, out of the box. Tu créés un projet avec Maven, tu vas avoir une fenêtre avec tes différents goals directement visibles et exécutables, pas de "Add Maven nature" ou de bidules mal foutus de ce genre.

La liste est loin d'être exhaustive. C'est juste une question d'angle de vue. L'ergonomie, c'est un truc qu'il faut avoir en tête dès la conception du truc. MÊME quand on s'adresse à de développeurs (parlez-moi des cordonniers, toujours les plus mal chaussés... Les développeurs, eux ont toujours les logiciels les moins intuitifs à utiliser).

[Mickael Baron]

C'est pour ça que je me demande pourquoi Eclipse et NetBeans ne cherchent pas à atteindre le même niveau de fonctionnalité et d'ergonomie...

Je dirais simplement qu'Eclipse ne se limite pas qu'à l'environnement de développement. C'est aussi une plateforme de modélisation très riche (EMF, Sirus...) et une plateforme de développement (RCP, RAP...). Je me limite à ce que je connais mais après son écosystème est monstreux.

Mickael

[plawyx]

j'attendais Luna avec impatience (support jdk 1.8). Sur ma debian 7 64 bits à jour, j'ai le résultat suivant (eclipse-jee-luna-R-linux-gtk-x86_64.tar.gz):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
(java:18640): GLib-GObject-WARNING **: cannot register existing type `GdkDisplayManager'
 
(java:18640): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed
 
(java:18640): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed
 
(java:18640): GLib-GObject-WARNING **: invalid (NULL) pointer instance
 
(java:18640): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
 
(java:18640): GLib-GObject-WARNING **: invalid (NULL) pointer instance
 
(java:18640): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
 
(java:18640): GLib-GObject-WARNING **: cannot register existing type `GdkDisplay'
 
(java:18640): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed
 
(java:18640): GLib-GObject-CRITICAL **: g_type_register_static: assertion `parent_type > 0' failed
 
(java:18640): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed
 
(java:18640): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f1f2245673f, pid=18640, tid=139772409038592
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b132) (build 1.8.0-b132)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b70 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libgdk-x11-2.0.so.0+0x5173f]  gdk_display_open+0x3f

Je vais donc continuer avec Kepler.

[plawyx]

j'attendais Luna avec impatience (support jdk 1.8). Sur ma debian 7 64 bits à jour, j'ai le résultat suivant (eclipse-jee-luna-R-linux-gtk-x86_64.tar.gz):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
(java:18640): GLib-GObject-WARNING **: cannot register existing type `GdkDisplayManager'
 
(java:18640): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed
 
(java:18640): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed
 
(java:18640): GLib-GObject-WARNING **: invalid (NULL) pointer instance
 
(java:18640): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
 
(java:18640): GLib-GObject-WARNING **: invalid (NULL) pointer instance
 
(java:18640): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
 
(java:18640): GLib-GObject-WARNING **: cannot register existing type `GdkDisplay'
 
(java:18640): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed
 
(java:18640): GLib-GObject-CRITICAL **: g_type_register_static: assertion `parent_type > 0' failed
 
(java:18640): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed
 
(java:18640): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f1f2245673f, pid=18640, tid=139772409038592
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b132) (build 1.8.0-b132)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b70 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libgdk-x11-2.0.so.0+0x5173f]  gdk_display_open+0x3f

Je vais donc continuer avec Kepler.

Après de nombreuses lecture, il s'avère que, par défaut, Luna utilse la GTK3 qui repose sur la glibc 2.14. Problème, la glibc sur wheezy est pour le moment la 2.13. Pour pouvoir utiliser Luna (sans attendre jessie), on doit ajouter les deux lignes lignes suivantes dans eclipse.ini:


--launcher.GTK_version
2

[dark.jabberwock]

Bonjour à tous,

Cette conversation, bien que parfois un peu houleuse, est très intéressante. Je commencerais néanmoins par la news en elle même et répondre aux quelques questions de Mickaël BARON.

Donc je trouve personnellement que Luna est un bon cru en terme de version d'Eclipse. Certains points sont encourageants pour l'avenir de l'IDE et pour la fondation en général. J'avoue que pour ceux qui ne suivent pas la communauté Eclipse, il est difficile d'avoir une bonne visibilité de l'état de santé des projets et donc de l'IDE.

J'utilise au travail Luna depuis la M6. C'est à dire depuis mars. Je n'ai pas eu de problèmes majeurs. Je n'ai pas non plus le souvenir d'avoir perdu un workspace ou autre trucs emmerdants. J'ai trouvé que l'IDE est plus agréable à utiliser.

Seul bémol de cette version pour moi est qu'il existe toujours quelques petits soucis sur l'inference de type en Java 8. J'ai rencontré un bug notamment visible au niveau du code source de fluent-http (Bug créé en cours de résolution). Bon après, il est contournable facilement sans réel coût (ajout de deux lignes de codes). Au fait, sacré boulot de la part des commiters. C'est si je ne me plante pas la première fois que le support d'une nouvelle version de Java sort officiellement en même temps que la version de Java. Ok ce n'était pas facilement testable avec un an d'avance comme pour Netbeans, mais c'est tellement mieux qu'avant.

Sinon, je félicite certaines initiatives ou améliorations telle que l'ajout d'un thème sombre ou l'affichage du numéro de ligne par défaut dans les éditeurs. Cela va dans le même sens que ce qu'attends une bonne part de la communauté de développeur utilisant Eclipse en IDE.

Question pour Mickaël Istria : est ce juste un ressenti ou il y a plus de sondages qu'avant pour améliorer l'IDE ? J'ai apprécié celui sur le numéro de ligne et sur le nouveau site Eclipse.

Maintenant passons à ce que je trouve très intéressant dans la conversation c'est à dire les griefs fait à l'IDE.

A mon avis, ymajoros n'a pas tord sur le fait qu'Eclipse devrait plus se caler sur maven que ce n'est le cas actuellement. Il y a des contournements mais certains points sont assez chiants. Par exemple, il n'y a qu'un seul classpath pour le projet. Le support de multiple classpath pour un projet n'est toujours pas géré (indépendant de l'implémentation de m2e). Ceci résulte dans la possibilité de faire référence à des classes du source folder de test dans le main. Plutôt flippant et ça casse bien entendu le build sur l'IC. D'ailleurs, heureusement qu'elle est là.

J'ai listé ci-dessous quelques problèmes de l'IDE. Soit ils sont venus dans la conversation, soit je les ai répertorié il y a peu de temps et je ne les ai pas encore posté sur le tracker d'Eclipse. Le but est d'en discuter, savoir si cela a déjà été remonté et potentiellement apporter des idées nouvelles.

Idées d'améliorations autour du composant m2e :

[1] Lors du lancement d'Eclipse et dans le cas où seule l'implémentation interne à l'IDE est présente, vérifier la présence de la variable d'environnement M2_HOME. Si celle-ci existe, alors proposer à l'utilisateur d'utiliser cette version de maven pour la construction des projets et faire un lien vers la configuration associée (settings.xml).
J'ajouterais également une préférence permettant de supprimer cette vérification dans le cas où l'utilisateur ne souhaite pas du tout utiliser l'implémentation présente sur son système mais uniquement celle de l'IDE.

[2] Lors de l'utilisation d'un projet maven, il est toujours possible d'éditer manuellement le classpath ou autre préférences relative au système de build. Dans un projet maven, la référence est le pom.xml. Il serait intéressant de désactiver la possibilité de modifier ces informations lorsque le projet possède la nature m2e. Ticket créé par Mickael Istria (https://bugs.eclipse.org/bugs/show_bug.cgi?id=439020)

[3] Créer un sélecteur de profil maven. Lors de l'utilisation des profils maven, il n'est pas facile de savoir où indiquer quels sont les profils que l'on veut usuellement utiliser (Clic droit > Properties > Maven > Profiles). Il serait plus intéressant d'avoir dans le menu de m2e une option amenant directement sur cet écran.
Cet écran pourrait également être revu afin d'indiquer quels sont les profils disponibles.
Eventuellement une liste avec des case à cocher pourrait être mise en place afin d'aider l'utilisateur.
Alors après vérification, dans le menu déroulant (Clic droit > Maven > ...) il y a une nouvelle option pour sélectionner les profils qui correspond à ce que je souhaitais. A noter que la partie "Properties" n'a pas évolué. Dommage ce n'est pas homogène.

[4] Permettre d'avoir plusieurs classpath selon les sources folders. Cela permettrait notament de gérer correctement les problèmes d'import/autocomplétion des classes de src/test/java dans src/main/java. A noter que plusieurs bugs existent déjà. Il n'est donc pas nécessaire de le remonter. Par contre, vous pouvez toujours vous inscrire et voter pour la résolution de ce problème. Les bugs concernés sont : https://bugs.eclipse.org/bugs/show_bug.cgi?id=398537 et https://bugs.eclipse.org/bugs/show_bug.cgi?id=356450

Autres points remontés :

[1] Création d'un menu d'import permettant d'importer les projets Netbeans directement dans Eclipse. Il serait nécessaire de détecter les fichiers Netbeans correspondant et convertir au format Eclipse (.projets, .settings...).

[2] Nettoyer la barre d'outils ? Trop de barre + haut de fenêtre. Beaucoup de place perdue. J'avoue ne pas trop savoir ce qui dérange le plus sur ce point. Je pense qu'un détail du problème, avec si possible des screenshots, permettrait de soumettre une demande d'amélioration à la communauté. A noter que certains points sont petit à petit amélioré sur cette partie là. Je pense notamment au "Quick Access" que l'on peut maintenant masquer.

[3] Effectuer les builds Eclipse en tâche de fond. Le build est incrémental mais parfois bloque l'utilisateur (impossible d'éditer / sauvegarder). Ce comportement est particulièrement frustrant lorsque l'on développe. D'autres IDE propose déjà des builds en tâche de fond. Par contre, la construction n'est pas incrémentale.

[4] Améliorer la version d'édition de l'IDE. Il semble que cela était plus rapide sur la branche 3.X. Peut-on avoir des exemples détaillés, l'environnement utilisé ?

Si vous avez des remarques, suggestions, n'hésitez pas. En fait, je suis convaincu que plus on explique les problèmes rencontrés, plus on a de chance d'obtenir des corrections à l'outil.

[ymajoros]

J'essaierai par curiosité, mais Eclipse est mort depuis longtemps pour moi. Un IDE qui ne supporte pas maven nativement (=pas de fichiers configs foireux à "synchroniser", qui a une gestion des tâches hasardeuses (le "building workspace" de 5 minutes dès qu'on a un gros projet et quelques "save actions"), qui ressemble plus à un bricolage de plugins de qualité variable... Je sais, c'est open source, mais un peu de recherche montre que c'est difficile à changer. Il faudrait repenser depuis le début. La gestion des projets n'est pas assez découplée de la config propriétaire actuelle, par exemple. Et rien que l'idée de toucher à SWT, quelle idée saugrenue au 21ème siècle ;-)

Aussi, je suis toujours surpris de voir qu'on propose toujours une seule alternative, payante (pour la grande partie des fonctionnalités)... alors qu'il y a aussi Netbeans, qui en fait plus pour le même prix (= rien) et n'a pas les problèmes décrit ci-dessus... Et a le support de Java 8 depuis... 1 an, bien avant sa sortie. Ou jdeveloper, un peu unique dans son genre mais très bien la dernière fois que j'ai essayé. Le monde des IDE n'est pas cantonné à Eclipse et IntelliJ...

[Mickael Baron]

C'est moi ou il n'y a que les "Mickael" qui aiment Eclipse

Mickael

[Mickael_Istria]

J'essaierai par curiosité, mais Eclipse est mort depuis longtemps pour moi. Un IDE qui ne supporte pas maven nativement (=pas de fichiers configs foireux à "synchroniser", qui a une gestion des tâches hasardeuses (le "building workspace" de 5 minutes dès qu'on a un gros projet et quelques "save actions")

Re-essaye des version recentes, il y a eu des fixes la-dessus.
Ensuite le debat sur Maven: les gens pensent tous que le Maven est natif dans NetBeans et IntelliJ, mais c'est en fait aussi vrai ou faux que pour Eclipse. NetBeans et IntelliJ ont aussi des modeles de projets interne, et ces IDE injectent aussi le contenu du pom dans le model interne. Il n'y a pas de difference fondamentale avec ce que fait m2eclipse.

qui ressemble plus à un bricolage de plugins de qualité variable...

Ca c'est definitivement vrai, et c'est une constante pour toutes le plateformes qui ont un gros ecosysteme: il y a a boire et a manger.

Je sais, c'est open source

Comme tu le dis apres, ce n'est pas une excuse, ni meme quelque chose a correler avec la qualite.

[ymajoros]

(build)

Re-essaye des version recentes, il y a eu des fixes la-dessus.

J'ai utilisé toutes les versions depuis 3 ans. Il y a des améliorations, mais c'est toujours foireux : désynchronisations, n'utilise pas vraiment Maven pour faire le build.

Ensuite le debat sur Maven: les gens pensent tous que le Maven est natif dans NetBeans et IntelliJ, mais c'est en fait aussi vrai ou faux que pour Eclipse. NetBeans et IntelliJ ont aussi des modeles de projets interne, et ces IDE injectent aussi le contenu du pom dans le model interne. Il n'y a pas de difference fondamentale avec ce que fait m2eclipse.

Non, il y a une différence fondamentale. Eclipse compile lui-même et a sa propre vision du projet. NB lance juste maven pour faire un build. Ou lancer (run), etc. Toutes ces actions sont des exécutions de maven, par ailleurs configurables. J'ai vu trop souvent des builds qui fonctionnent dans Eclipse, puis plus sous Jenkins. Ça n'arrive pas quand le même outil (maven) est utilisé dans tous les cas.

Il n'y a pas d'excuse pour qu'Eclipse continue à faire des builds à sa manière pour des projets Maven, c'est juste bon à jeter.

Je pense que le modèle de projets d'Eclipse manque d'abstraction et est trop difficile à corriger, et je ne m'attends pas à ce que ça bouge de sitôt. C'est la différence entre un outil où toutes les contributions ou presque sont les bienvenues, et un outil dont le dev est géré sérieusement. Le premier ressemble à un tas de plugins de qualité variables (NPE aléatoires, ...). Mes contributions pour NB se sont vues refusées plusieurs fois avant d'être acceptées : il y a juste une vision globale qui manque totalement au développement d'Eclipse.

[plawyx]

a une gestion des tâches hasardeuses (le "building workspace" de 5 minutes dès qu'on a un gros projet et quelques "save actions").

Est-ce vraiment le rôle d'un IDE, quel qu’il soit. Pour les builds et bien d'autres choses, il y a JENKINS qui fait cela très bien.

[ymajoros]

Est-ce vraiment le rôle d'un IDE, quel qu’il soit. Pour les builds et bien d'autres choses, il y a JENKINS qui fait cela très bien.

Ou juste maven (par ex.), que jenkins peut démarrer de la même manière que l'IDE.

Le problème, c'est quand Eclipse bloque tout pendant 5 minutes. Bien sûr, il doit construire le projet pour marquer ce qui ne compile pas etc. Je ne veux juste pas que mon IDE m'empêche de bosser pour ça.