Discussion :

[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.

[Laurent.B]

On a des raisons d'être agacé par cet IDE mais faut garder espoir, participer... les choses avancent malgré tout. Personnellement, je suggérerai bien aux personnes en charge du projet, de faire un break dans leur release train parce qu'ajouter des fonctionnalités, sans corriger la multitude de bugs gênants préalablement, ça ne donne pas confiance en l'avenir.

Voilà ben finalement c'est fait : https://bugs.eclipse.org/bugs/show_bug.cgi?id=442516