Discussion :

[Mickael_Istria]

Par exemple, dégager complètement le .project et tout faire avec du pom.xml [...] J'ai du mal à imaginer que ça puisse bien passer.

Quelle serait l'avantage? En quoi le .project est-il un probleme pour l'utilisateur?
En quoi le .project est-il moins bien que le "nbproject" de NetBeans ou le .iml d'IntelliJ?

Ce genre de suggestion (supprimer le .project) ne sera en effet pas forcement bienvenue. Cette suggestion est en fait liee a des problemes fonctionnels qui font que tu accuses le .project. Les problemes fonctionnels sont plutot ce qui est recherche par rapport aux solutions d'architecture.

Déjà, c'est toujours une pièce rapportée, c'est à dire un plugin optionnel.

Ce n'est plus vrai depuis Kepler: https://www.eclipse.org/downloads/pa...elopers/lunar#

Ensuite, on peut toujours ajouter des bibliothèques directement dans le projet Eclipse (même si on a créé directement un projet Maven).

Voila une bonne suggestion fonctionnelle: Desactiver la possibilite d'editer le classpath et autre preferences de JDT quand le project est gere par m2eclipse. Je te laisse decrire ca sur http://bugs.eclipse.org

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.

Tu veux parler du settings.xml? Si oui, la version que j'ai de m2eclipse utilise par defaut le settings.xml de ton $HOME/.m2, ce qui semble corresponde au comportement que tu souhaites.

[spidetra]

Premier test de Luna:
1. Installation des e4 tools : http://download.eclipse.org/e4/updates/0.14
2. Création d'un projet Eclipse 4.
3. Impossible d'ouvrir le fichier : e4xmi => NPE
4. Plus aucun éditeur ne s'ouvre => NPE

En fait pour les autres éditeurs la NPE ne se produit que si le fichier .e4xmi est ouvert.
Pour l'instant impossible de faire une appli e4 avec Luna.

[Mickael_Istria]

Pas cool...
C'est peut-etre plutot un bug de e4 tools que de Luna... T'as regarde si il est deja dans le tracker?

[spidetra]

Pas cool...
C'est peut-etre plutot un bug de e4 tools que de Luna... T'as regarde si il est deja dans le tracker?

Non, j'ai testé rapidement hier soir pour voir comment avait évoluer le support de e4 dans Luna.
C'était juste par curiosité.

[if_zen]

Bizarre, ils sont restés sur la mode des gros onglets à bords arrondis. Ils n'ont pas suivi la mode de tout remettre à plat.
Je trouve qu'il y a énormément de place perdue à cause de cela. Vu le nombre de fenêtres internes dans l'IDE ça a son importance, même si on a un grand écran.

Perso je vais attendre quelques màj, en général au début les nouvelles versions sont d'une stabilité moyenne.

Edit : + notez les 4 barres d'outils (avec la barre de titre ok) dont 50% de la surface est inutilisée. Et tous les boutons ne sont pas supprimables, même les plus inutiles (ou alors j'ai pas trouvé)

[Killing Joke]

Bizarre, ils sont restés sur la mode des gros onglets à bords arrondis. Ils n'ont pas suivi la mode de tout remettre à plat.
Je trouve qu'il y a énormément de place perdue à cause de cela. Vu le nombre de fenêtres internes dans l'IDE ça a son importance, même si on a un grand écran.

Perso je vais attendre quelques màj, en général au début les nouvelles versions sont d'une stabilité moyenne.

Je te rejoins tout à fait sur les deux points (thème par défaut vraiment peu esthétique et peu pratique - trop de place perdue - et premières versions pas toujours très stables).

Le thème "dark" est assez raté, sur mon Windows 7 il y a plein de petits soucis graphiques (genre les flèches de sélections sur les treeviews qui sont en noir sur fond noir et sont donc invisibles). Pas très carré au final ...

J'aimerais surtout qu'ils améliorent la vitesse d'édition au sein des éditeurs de code, c'est toujours plus lent que sur la branche 3.x (çà ne gêne surement pas grand monde à part moi, celà dit, mais pour ma part je n'aime pas cette impression de lenteur qu'il y a quand on cherche à naviguer rapidement).

Sinon j'utilise toujours Eclipse pour ma part, que je trouve globalement bien et tout à fait utilisable même si loin d'être parfait. Je n'ai pas encore assez creusé IdeaJ pour vraiment réussir à y switcher.

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

[ymajoros]

@ymajoros: Quand tu codes du IJ ou du NB, tu fais du Swing, c'est encore pire...

Pire ? Pq ? Au moins du vrai MVC, pas de librairies natives, etc. Type safe (nettes améliorations dans les dernières jdk). Et ne me raconte pas que SWT est plus performant, c'est juste faux depuis 10 ans.

Ensuite, tu peux faire (rien) en désactivant le 'Build automatically' d'Eclipse, du coup, tu arrives à Iso des fonctionnalités des autres Ide (IJ ou NB) et les mêmes perfs,

ISO ? Genre, il ne builde plus ton projet = ISO ? Netbeans build en tâche de fond (vraiment, pas comme Eclipse).

Aussi, quand je veux faire un build, ou lancer le projet, c'est maven, et uniquement maven, qui est exécuté. Ce n'est pas le cas d'Eclipse (ex. : sa notion de "classpath" différente de celle de maven).

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

[UMLTECH]

Au risque de surprendre, Eclipse n'est pas un IDE ... mais une plate-forme d'intégration. La partie IDE n'est qu'un plugin parmi d'autres (même si il a rôle important).

Eclipse n'est peut-être pas au niveau d'autres IDE, mais surpasse tous les autres outils quand on veut intégrer des plugins ensemble. Perso, j'ai réaliser un modeleur (définition de stratégies d'entreprise) en quelques semaines seulement et quasiment sans aucun bug. Technos utilisées (UML2, EMF, Sirius, Java, RCP, OSGi). Autre techno à venir 'CDO'.

Quel autre outil m'aurait permis cela ? ... aucun !

[Mickael Baron]

Au risque de surprendre, Eclipse n'est pas un IDE ... mais une plate-forme d'intégration. La partie IDE n'est qu'un plugin parmi d'autres (même si il a rôle important).

+1

Mickael

[ymajoros]

Au risque de surprendre, Eclipse n'est pas un IDE ... mais une plate-forme d'intégration. La partie IDE n'est qu'un plugin parmi d'autres (même si il a rôle important).

Ceci explique cela. Même si je suis curieux de voir une explication plus ou moins officielle.

[ymajoros]

Quelle serait l'avantage? En quoi le .project est-il un probleme pour l'utilisateur?
En quoi le .project est-il moins bien que le "nbproject" de NetBeans ou le .iml d'IntelliJ?

Ce genre de suggestion (supprimer le .project) ne sera en effet pas forcement bienvenue. Cette suggestion est en fait liee a des problemes fonctionnels qui font que tu accuses le .project. Les problemes fonctionnels sont plutot ce qui est recherche par rapport aux solutions d'architecture.


Ce n'est plus vrai depuis Kepler: https://www.eclipse.org/downloads/pa...elopers/lunar#

Ah, voici un bon exemple. Ce que tu dis n'est pas juste, et c'est justement ce qui pose problème avec Eclipse/

Il n'y a pas de dossier "nbproject" pour un projet maven avec Netbeans. Le seul fichier nécessaire à son ouverture est... le pom.xml . C'est la grosse différence, au lieu "d'importer" un projet maven et de le lancer via l'IDE, on l'ouvre simplement (pas d'importation). Quand on le lance (ou quand on le construit etc.), c'est une commande maven qui est exécutée. Il y a bien 2 fichiers propres à Netbeans, mais qui ne sont pas strictement nécessaires : nbactions.xml dit quelle action exécuter pour chaque action dans l'IDE ("build", "clean", ...) et nb-configuration.xml contient des options supplémentaires indépendantes de Maven, et ne sont donc pas dans le pom.xml .

En d'autres termes, ce qui pose problème n'est pas le .project, mais le fait qu'il soit la référence pour Eclipse au lieu du pom.xml (en plus d'être redondant).

La différence entre Netbeans et Eclipse à ce sujet est qu'il n'y a pas de configuration à synchroniser : tout est dans le pom.xml et tout le reste est superflu. Aussi, même si je le répète : c'est maven qui construit le projet, pas l'IDE. En ce sens, Eclipse a un modèle complètement dépasser, à jeter au plus vite.

[spidetra]

Au risque de surprendre, Eclipse n'est pas un IDE ... mais une plate-forme d'intégration. La partie IDE n'est qu'un plugin parmi d'autres (même si il a rôle important).

Eclipse n'est peut-être pas au niveau d'autres IDE, mais surpasse tous les autres outils quand on veut intégrer des plugins ensemble. Perso, j'ai réaliser un modeleur (définition de stratégies d'entreprise) en quelques semaines seulement et quasiment sans aucun bug. Technos utilisées (UML2, EMF, Sirius, Java, RCP, OSGi). Autre techno à venir 'CDO'.

Quel autre outil m'aurait permis cela ? ... aucun !

Salut,
On travaille sur les mêmes technos (EMF, GMF, xTend, etc...), et certainement sur des projets assez similaires.
Sur ce point on est d'accord à 300%, Eclipse surclasse ses compétiteurs. Et des nouveaux projets comme Siruis (merci Obeo), vont encore plus nous simplifier la vie dans la création de nos modeleurs.

Mais, sur 100 utilisateurs d'Eclipse, tous langages confondus, combien sont uniquement à la recherche d'un très bon IDE, et pas plus ?

Je n'ai pas de stats fiables pour répondre à cette question. Le projet UDC a été stoppé, et je ne sais pas si des données de ce projet sont dispo quelques part.
Je me suis amusé à faire des stats en utilisant les données des téléchargements de Luna.



94% des téléchargements correspondent à des packaging de types IDE, et seulement 6% à des packaging de type frameworks modélisation.

Il n'est évidemment pas possible de déduire directement de ces données l'utilisation qui est faîtes d'Eclipse.
Mais le ratio 90/10, ne me semble pas aussi aberrant que ça.
90% des utilisateurs utiliseraient Eclipse comme simple IDE et seulement 10% comme framework de dev.
Dans ma dernière mission, le ratio était bien inférieur à 10%: 3 devs RCP contre plus 100 devs JEE.

Il serait intéressant d'avoir des données plus fiables: à partir d'un sondage, ou encore mieux directement à partir des données de la fondation Eclipse (collectées au travers du projet UDC).

La fondation Eclipse n'investit certainement pas 80 à 90% de ses fonds et de ses ressources dans le développement de l'IDE. Et c'est normal.
Mais l'IDE devrait quand même rester LA priorité numéro un de la Fondation. Et c'est loin d'être le cas (Cf. le post sur EasyEclipse et KickStarter).

[Mickael_Istria]

La fondation Eclipse n'investit certainement pas 80 à 90% de ses fonds et de ses ressources dans le développement de l'IDE. Et c'est normal.

Pour info, la Fondation Eclipse n'investit quasiment rien dans les projets qui sont developpes par le COMMUNAUTE Eclipse. Les investisseurs sont les contributeurs, individuels ou entreprises, qui developpent effectivement Eclipse.
Les descriptions formelles de la fondation sont disponibles ici, et son dernier rapport d'acitivite la. On voit bien que la Fondation est plutot une pepiniere, dont le souci est la creation d'activite, et en aucun cas le developpement de code ou la gestion de produit.

Mais l'IDE devrait quand même rester LA priorité numéro un de la Fondation. Et c'est loin d'être le cas (Cf. le post sur EasyEclipse et KickStarter).

Ce sont les contributeurs qui font les choses et qui decident des priorites et qui decident de combien de personnes ils veulent faire travailler (dans leurs propres staffs) sur quels sujets.
Le pouvoir est a ceux qui font.

[Mickael_Istria]

Ah, voici un bon exemple. Ce que tu dis n'est pas juste, et c'est justement ce qui pose problème avec Eclipse

Focalise toi sur les vrais problemes d'usage, c'est ceux-ci qu'il faut resoudre, pas forcement besoin de tout revolutionner, il suffirait que tu listes des projets ou des exemples concrets ou ca ne marche pas, et ca sera de bonnes perspectives d'amelioration.

Il n'y a pas de dossier "nbproject" pour un projet maven avec Netbeans. Le seul fichier nécessaire à son ouverture est... le pom.xml . C'est la grosse différence, au lieu "d'importer" un projet maven et de le lancer via l'IDE, on l'ouvre simplement (pas d'importation).

Ok, mais ce dont tu parles la, c'est juste que le process d'ouverture d'un project Maven dans NetBeans est plus simple que celui d'Eclipse, ce qui est tout a fait vrai. Creer un menu "Open Project" dans Eclipse n'a rien a voir avec l'existence ou non d'un .project. C'est le sujet d'une discussion: https://bugs.eclipse.org/bugs/show_bug.cgi?id=421930
D'ailleurs, j'ai un plugin qui ajoute un menu Open Project, qui permet d'ouvrir des projets (notamment Maven) plus simplement: https://github.com/mickaelistria/jbosstools-eclipse . Feedback et contributions bienvenus bien sur.


Ce qui serait vraiment cool, c'est si tu peux donner des exemples concrets de projets ou de cas d'usage dans lesquels Eclipse et m2e ont un comportement qui ne tient pas la route. A partir de la, ce sera plus simple d'ameliorer les choses.

[ymajoros]

Focalise toi sur les vrais problemes d'usage, c'est ceux-ci qu'il faut resoudre, pas forcement besoin de tout revolutionner, il suffirait que tu listes des projets ou des exemples concrets ou ca ne marche pas, et ca sera de bonnes perspectives d'amelioration.

Le fait qu'Eclipse gère les projets à sa sauce (ouverture comme exécution) est bien en problème en soi :

1) il empêche d'ouvrir des projets qui ne sont pas créés pour Eclipse ou qui ne tombent pas dans les cas d'usages prévus ; dès que le build maven est un peu complexe (et pas développé sous Eclipse pour qu'il marche spécifiquement sous ce dernier), on a un gros risque de problème ; je pense par exemple aux annotation processors, qui nécessitent plein de config spécifique à Eclipse pour qu'ils fonctionnent ; si mvn install fonctionne, ça devrait marcher sous tout IDE ; on peut trouver des tas d'exemples similaires, en fait dès qu'on dépasse le bête build
2) ça donne des mauvaises habitudes : on ne fait pas le build comme il faudrait, mais pour qu'il marche sous Eclipse ; je pense à tous ces cas courants de tests junit qui marchent dans Eclipse puis plus en ligne de commande ou sous Jenkins, à l'utilisation de "maven-eclipse-plugin", aux générations de clients web service qui ne déposent pas les fichiers dans generated-sources comme ils devraient...
2bis) ça fait que bcp de boîtes continuent à utiliser uniquement Eclipse, parce que les projets développés avec ne s'ouvrent pas facilement dans d'autres IDE. Ce n'est bon pour personne, c'est même néfaste pour Eclipse qui n'évolue pas de par cet immobilisme.

Je me "focalise bien sur des vrais problèmes d'usage", c'est une plaie. Et je ne parle pas des NPE, des "Building workspace" qui bloquent l'interface, ...

Ici, résoudre le vrai problème n'est pas une révolution. Lancer les projets maven avec... maven, ce n'est pas une idée saugrenue, c'est la base. Les autres IDE ont compris, pourquoi ne peut-on pas corriger ça une bonne fois pour toutes dans Eclipse ?

Ok, mais ce dont tu parles la, c'est juste que le process d'ouverture d'un project Maven dans NetBeans est plus simple que celui d'Eclipse, ce qui est tout a fait vrai. Creer un menu "Open Project" dans Eclipse n'a rien a voir avec l'existence ou non d'un .project. C'est le sujet d'une discussion: https://bugs.eclipse.org/bugs/show_bug.cgi?id=421930

Non, c'est le fait que le pom.xml doit être la référence, pas une source intermédiaire pour générer une configuration de projet. Avoir un menu qui lance l'import ne m'aidera pas, je ne veux pas d'import du tout même derrière mon dos. Tant que ce n'est pas Maven qui est appelé derrière les différentes actions, ça ne peut pas être 100 % fonctionnel. À moins de réécrire maven et tous ses plugins, mais à quoi bon quand il suffit de lancer... Maven. Le concept n'est pas chinois, qu'est-ce qui coince ?

Ce qui serait vraiment cool, c'est si tu peux donner des exemples concrets de projets ou de cas d'usage dans lesquels Eclipse et m2e ont un comportement qui ne tient pas la route. A partir de la, ce sera plus simple d'ameliorer les choses.

Des projets spécifiques ? J'en ai rencontré beaucoup au quotidien. Je n'ai pas d'exemple de projet open source (pas ceux que j'ouvre le plus dans Eclipse), mais je suis prêt à parier que si tu ouvres les différents composants de Glassfish dans Eclipse (par ex), ça ne marchera pas sans chipoter. Ça vaut probablement pour des tas de projets : je serais curieux de voir quel proportion de projets, corrects au niveau maven, ne s'ouvrent pas bien dans Eclipse (du premier coup, sans changer le classpath, etc. ...).

Je suppose que les limitations de m2e-eclipse sont listées, on peut tenter de les résoudre une par une (bonne chance)... ou résoudre encore le problème à la source, ce qui serait bcp plus sain.

[Mickael_Istria]

1) il empêche d'ouvrir des projets qui ne sont pas créés pour Eclipse ou qui ne tombent pas dans les cas d'usages prévus ; dès que le build maven est un peu complexe (et pas développé sous Eclipse pour qu'il marche spécifiquement sous ce dernier), on a un gros risque de problème ; je pense par exemple aux annotation processors, qui nécessitent plein de config spécifique à Eclipse pour qu'ils fonctionnent ; si mvn install fonctionne, ça devrait marcher sous tout IDE ; on peut trouver des tas d'exemples similaires, en fait dès qu'on dépasse le bête build

T'as essaye avec m2e-apt? http://marketplace.eclipse.org/content/m2e-apt
Et d'ailleurs t'as essaye d'autres IDEs bases sur Eclipse, genre JBoss Developer Studio, ou ce genre de choses sont packagees par default?

je pense à tous ces cas courants de tests junit qui marchent dans Eclipse puis plus en ligne de commande ou sous Jenkins, à l'utilisation de "maven-eclipse-plugin", aux générations de clients web service qui ne déposent pas les fichiers dans generated-sources comme ils devraient...

Ok, pour ces exemples. Le maven-eclipse-plugin est clairement quelquechose de mauvais que plus personne ne devrait utiliser. Apres, les mauvaises habitudes ont la vie dure...
Quant aux clients Jax-WS, il semblerait qu'il n'y ait en effet pas de connecteur. Ceci dit, m2e te permets d'executer le mojo au bon moment s'il n'y a pas de connecteur: https://wiki.eclipse.org/M2E_plugin_...te_plugin_goal

2bis) ça fait que bcp de boîtes continuent à utiliser uniquement Eclipse, parce que les projets développés avec ne s'ouvrent pas facilement dans d'autres IDE. Ce n'est bon pour personne, c'est même néfaste pour Eclipse qui n'évolue pas de par cet immobilisme.

Je pense que tu as un interpretation tres personnelle de pourquoi les boites continuent a utiliser Eclipse.

Et je ne parle pas des NPE, des "Building workspace" qui bloquent l'interface, ...

Justement, c'est des scenarios pour reproduire ce genre d'erreurs qui sont le plus interessants.

Non, c'est le fait que le pom.xml doit être la référence, pas une source intermédiaire pour générer une configuration de projet. Avoir un menu qui lance l'import ne m'aidera pas, je ne veux pas d'import du tout même derrière mon dos. Tant que ce n'est pas Maven qui est appelé derrière les différentes actions, ça ne peut pas être 100 % fonctionnel. À moins de réécrire maven et tous ses plugins, mais à quoi bon quand il suffit de lancer... Maven. Le concept n'est pas chinois, qu'est-ce qui coince ?

Le concept n'est pas mauvais et je soutiens l'idee (cf https://dev.eclipse.org/mhonarc/list.../msg01659.html ). Apres, le concept de m2e est d'integrer maven dans le build incremental d'Eclipse, donc ce genre de requete n'est pas la priorite compare a creer les bons connecteurs.

Des projets spécifiques ? J'en ai rencontré beaucoup au quotidien. Je n'ai pas d'exemple de projet open source (pas ceux que j'ouvre le plus dans Eclipse)

Ok, dommage.

[ymajoros]

T'as essaye avec m2e-apt? http://marketplace.eclipse.org/content/m2e-apt

C'est exactement ce que je ne trouve pas normal : devoir installer des plugins (qualité et résultats variables) et faire de la config alors que tout est dans le pom.xml .

[...]

Quant aux clients Jax-WS, il semblerait qu'il n'y ait en effet pas de connecteur. Ceci dit, m2e te permets d'executer le mojo au bon moment s'il n'y a pas de connecteur: https://wiki.eclipse.org/M2E_plugin_...te_plugin_goal

[...]

Apres, le concept de m2e est d'integrer maven dans le build incremental d'Eclipse, donc ce genre de requete n'est pas la priorite compare a creer les bons connecteurs.

C'est justement cette approche que je critique. On se retrouve à devoir doubler chaque plugin maven par un "connecteur". Quelle idée, au lieu de juste... lancer Maven !

Je pense que tu as un interpretation tres personnelle de pourquoi les boites continuent a utiliser Eclipse.

Tu en as une universelle ?

[Laurent.B]

Tu en as une universelle ?

Pourquoi en veux-tu une universelle ? Tu donnes l'impression d'avoir une vision très étriquée de ce à quoi sert Eclipse. Faut-il te rappeler depuis quand cet IDE existe, son ouverture, ses principes intrinsèques, sa communauté... ? Tu dois quand même bien te douter que tout ne tourne pas autour de Maven ?

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.