L’environnement de développement Eclipse 4.3 est disponible

Posté par  (site web personnel) . Édité par ZeroHeure, claudex, palm123, bubar🦥 et Nÿco. Modéré par claudex. Licence CC By‑SA.
Étiquettes :
33
30
juin
2013
Java

La Fondation Eclipse vient d’annoncer la disponibilité d’une nouvelle version de l’environnement de développement libre Eclipse numéroté 4.3, nom de code Kepler, pour Linux, Mac OS X et Windows.

Eclipse

Eclipse Kepler se compose de 71 projets, ce qui représente 58 millions de lignes de code. Cette nouvelle version prend en charge Java EE 7 (sorti le 12 juin dernier) et apporte de nouvelles améliorations concernant l’interface et les performances.

Kepler apporte de nouvelles améliorations concernant l’interface et les performances. Les nouvelles fonctionnalités sont nombreuses, bien détaillées et illustrées de captures d’écran - cliquez sur les liens ci dessous. Voir la liste en français en seconde partie.

D'après l'annonce de presse

Comme chaque année, la communauté Eclipse coordonne une sortie majeure de ses projets Open Source fin juin.
Cette sortie simultanée est une bonne illustration de l'efficacité des processus de développement en logiciel libre : appliqués ici au développement distribué à grande échelle (Eclipse Kepler réunit 71 projets, 420 développeurs et plus de 58 millions de lignes de code), elle permet aux utilisateurs de mettre à jour, en une fois, les nouvelles versions de leurs projets, en s'appuyant sur un agenda prévisible de sortie.

Eclipse est une plateforme de développement ouverte composée de frameworks extensibles, outils et runtimes pour construire, déployer, et gérer le cycle de vie logiciel.

Voici quelques-unes des principales nouveautés pour Kepler :

Support de Java EE7

– La version 3.5 du projet Eclipse Web Tools (WTP) apporte le support de Java EE 7, lui-même récemment publié, incluant le support pour JPA 2.1, JSF 2.2, JAX-RS 2.0, Servlet 3.1, EJB 3.2, Connector 1.7, App Client 7.0 et EAR 7.0.
Les assistants de création, les aides au contenu et de validation ont été mis à jour.

Nouvelle suite pour la gestion des processus métier

– Eclipse Stardust 1.0 apporte un moteur et des outils de gestion de processus métier. Eclipse Stardust inclut un environnement de modélisation qui permet de créer et de débugger les modèles de workflow, un moteur de processus pour exécuter des applications BPM, un portail web pour les exécutions basées sur un navigateur et la surveillance des processus métier et un composant de reporting basé sur BIRT pour la surveillance d’exécution et le reporting des applications BPM.

Extensibilité et utilisation d’un IDE basé sur le web

– Orion 3.0 apporte des améliorations sur l’utilisation et l’extension de l’IDE web Orion. Il peut maintenant être facilement installé comme un fichier WAR dans un serveur d’applications Java, permettant de déployer vers des services cloud plus facilement. L’utilisation d’Orion a également été améliorée pour inclure la navigation de fichiers directement dans l’éditeur, de nouveaux raccourcis (vi et Emacs), sauvegarde automatique / chargement automatique et un nouveau style visuel.

Nouveau support pour le Big Data

– Eclipse BIRT 4.3 introduit le support des bases de données MongoDB et Cassandra et permet une intégration simplifiée pour les capacités de visualisation BIRT dans des applications Big Data. C’est un ajout au support existant d’Hadoop fourni par BIRT.

Meilleure intégration pour la revue de code

– Grâce à Mylyn 3.9, il est désormais beaucoup plus facile de réaliser des revues de code dans Eclipse. La nouvelle vue navigateur intégrée avec Gerrit démontre la vue structurée de tous les fichiers et commentaires d’une revue.

Amélioration de l’intégration avec Maven pour les développeurs JavaEE

– Nouveau support pour l’intégration Maven avec le projet Eclipse Web Tools (WTP) fournissant un ensemble de connecteurs qui ajoute le support Maven pour les projets Eclipse Java EE, incluant les projets war, ejb, et rar.

Nouveautés de l'interface

Changements ergonomiques

  • Les fenêtres peuvent être détachées sur plusieurs moniteurs tout en restant à jour ;
  • Assistant de migration pour les installations partagées d'Eclipse ;
  • Correction d'installation ;
  • Les barres d'outils peuvent être repositionnées ;
  • Raccourcis dans le dialogue d'ouverture de ressources ;
  • Les recherches peuvent se faire sur des mots entiers ;
  • La fenêtre de dialogue s'ouvre avec le dernier mot recherché ;
  • Une option de lancement permet maintenant d'arrêter un plugin bogué sans arrêter Eclipse.

Développement

  • SWT pour GTK3
  • Améliorations de performances.

Outils

  • Importation projets imbriqués ;
  • Les warnings peuvent être affichés au lancement d'une fenêtre de configuration ;
  • Une option permet de ne pas utliser -XstartOnFirstThread ;
  • Prise en charge de augment task pour Ant.

Aller plus loin

  • # Maven

    Posté par  . Évalué à 8.

    Le support de maven se fait toujours via un plugin assez mal intégré où ça c'est bien amélioré ? C'est la principale chose qui m'a fait quitter eclipse pour netbeans (je suis depuis passé à intellij pour d'autres raisons).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Maven

      Posté par  (site web personnel) . Évalué à 2.

      effectivement sous eclipse, il est assez moyen

      je préfère à ce niveau netbeans, beaucoup mieux géré

      www.solutions-norenda.com

    • [^] # Re: Maven

      Posté par  . Évalué à 2.

      Il est bien intégré maintenant, disponible dans le dépôt officiel, et ça fait quelques temps quand même, au mois 1 an, si ce m'est plus…

    • [^] # Re: Maven

      Posté par  . Évalué à 1.

      Maven est de mieux en mieux géré dans Eclipse mais il ne faut pas perdre de vue que le fonctionnement des "builds" dans Eclipse n'est pas fondé sur Maven contrairement à Intellij par exemple. Personnellement j'utilise Maven dans Eclipse pour fabriquer, mettre en paquets, etc. mais pas pour exécuter des programmes ou des tests.

  • # Améliorations surprenantes

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    J'ai été assez époustouflé en voyant certaines améliorations ici.

    Le quickfix, par exemple, permet maintenant :
    * de transformer des conditions if-else en switch en un clique
    * d'inverser une condition dans un if (l'exemple montré, est simple, peut-être que ce n'est pas possible avec une condition plus complexe)

    et il y a eu aussi pas mal d'améliorations pour la compilation (utilisation de @Nullable prise en considération et avertie lors de override,…) et du débuggage.

    Je ne sais pas si c'était déjà des choses faites dans d'autres IDEs, mais je trouve ces améliorations intéressantes.

    • [^] # Re: Améliorations surprenantes

      Posté par  (site web personnel) . Évalué à 8.

      Intellij IDEA est actuellement en version 12.1 et je ne connais pourtant que la version 6.1 et pourtant cet IDE faisait déjà ce genre de chose et plus encore. Bon par contre c'est un IDE payant et dont la version gratuite est limitée en fonctionnalités.

      If-else to switch

      Maintenant je fais du .Net sous Visual Studio et je pleure.

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: Améliorations surprenantes

        Posté par  (site web personnel) . Évalué à 5.

        Est-ce que tu connais ReSharper ?

        C'est un plugin pour Visual Studio de JetBrains, le même auteur qu'IntelliJ et qui apporte le même genre de fonctionnalités de refactoring, d'analyse de code et d'intellisense.

        Par contre les licences sont pas données (199$ pour un particulier, 349$ pour une licence commerciale), mais la version de test te permet de te faire un avis sur l'outil.

        • [^] # Re: Améliorations surprenantes

          Posté par  (site web personnel) . Évalué à 2.

          Oui je connais. Mais va falloir convaincre ma boîte pour payer une licence et c'est pas gagné. Déjà qu'on est toujours en Visual Studio 2008 :(

          L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

          • [^] # Re: Améliorations surprenantes

            Posté par  . Évalué à 2.

            As-tu déjà regardé du côté de Monodevelop/Xamarin Studio, je l'utilise pour de petites applications console C#, et je le trouve vraiment sympa (tout n'est cependant pas supporté - applications web, développement WinCe (oui ça existe encore… :( )

            • [^] # Re: Améliorations surprenantes

              Posté par  (site web personnel) . Évalué à 1.

              Je suis un développeur pressé moi Monsieur ! Je fais de l'ASP.Net MVC et tout et tout.

              D'après ce que j'ai vu avec des prestas ayant un peu plus de bouteille en .Net que moi, Visual Studio reste le meilleur pour ça :-/

              L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

          • [^] # Re: Améliorations surprenantes

            Posté par  . Évalué à 4. Dernière modification le 01 juillet 2013 à 11:10.

            Déjà qu'on est toujours en Visual Studio 2008 :(

            Vu que tout le code produit avec est incompatible avec les versions suivantes c'est "très" légèrement compréhensible que ta boite reste avec cette version.

            Ce fut une découverte très bizarre pour moi (et toujours incompréhensible) de voir qu'il est impossible de compiler sans faire de changement dans le code d'une version à l'autre de VS. Je comprend de moins en moins le pourquoi du "succés" de Windows et je l'explique de plus en plus par la vente forcé. Il ne peut pas y avoir d'autre raison! A moins d'être masochiste!

            Et je ne parle même pas du fait que l'équivalent des Makefiles soient tous version dépendante de VS…

            • [^] # Re: Améliorations surprenantes

              Posté par  . Évalué à 6.

              Il ne peut pas y avoir d'autre raison! A moins d'être masochiste!

              Certains aiment bien se faire mal…

              Oui! Plus fort! Vas-y fouette moi! J'adore ça!

              Si l'on prend du Microsoft, on s'enferme petit a petit dans un environnement, voire une logique où la moindre extension/personnalisation demande d'utiliser leurs outils, et l'on arrive alors a faire du .Net et autre joyeusetés.

              • [^] # Re: Améliorations surprenantes

                Posté par  . Évalué à 10.

                Oui! Plus fort! Vas-y fouette moi! J'adore ça! Utilise-moi pendant le temps qui te convient, Christine L.

            • [^] # Re: Améliorations surprenantes

              Posté par  . Évalué à 2. Dernière modification le 01 juillet 2013 à 14:08.

              Oui c'est vrai que c'est compliqué de double-cliquez sur un projet d'avoir un assistant d'upgrade et d'upgrader le projet. Au pire depuis VS2010 il me semble qu'on peut juste éditer le numéro de version dans le fichier XML et ça fonctionne aussi.
              Alors on va me dire que c'est quand même plus simple d'utiliser les autotools, editer les macros qui ne marchent plus avec la nouvelle version, regénerer le configure mais moi je ne trouve pas.
              Bref perso je suis heureux avec Visual et je n'ai jamais eu de souci que je ne pouvais résoudre en très peu de temps.

              • [^] # Re: Améliorations surprenantes

                Posté par  . Évalué à 7.

                Et garder la compatibilité, c'était pas possible ? C'est comme si le premier MS Office lisant les .docx ne savait plus gérer les .doc et obligeait à convertir les fichiers…

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à -10.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Améliorations surprenantes

                    Posté par  . Évalué à 10.

                    Quelle est le rapport entre Linux et Eclipse ?

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Améliorations surprenantes

                    Posté par  . Évalué à 3.

                    Les IDE font de la merde dans leur « fichiers de projets » c'est le cas de tous. C'est de la daube et ça le resteras longtemps. Une fois qu'on a compris ce principe de base et qu'on a compris que devoir passer par l'IDE pour construire le projet c'est la pire façon qu'il existe de faire, on commence à se tourner vers les builders (make, (n)ant, maven ou gradle par exemple).

                    Les avantages sont énormes :

                    • tu maîtrise tes fichiers projets (c'est généralement bien mieux documenté)
                    • tu choisi quand tu fait tes mises à jours de fichiers projet
                    • tu es capable de construire ton projet à partir des sources sans IDE (et hop une intégration continue facilité)
                    • tu as moins de code généré (tu maîtrise réellement tout le projet)

                    À partir de là tu peut envoyer bouler les IDE qui gèrent mal tes fichiers projets.

                    Pour maven ne cherchez pas, netbeans est l'IDE qui gère ça le mieux. Un pom.xml est un fichier de projet pour netbeans (il n'y a pas d'importation ou d'exportation).

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Améliorations surprenantes

                      Posté par  . Évalué à 3.

                      Eclipse ne m'a jamais fait de misère (j'utilise au choix eclipse/netbeans/intellij selon l'environnement et les besoins) mais je me demande si tout le monde est d'accord sur ce qu'est un "fichier projet".

                      Par ce que si tu utilises ton IDE sérieusement, ce n'est pas par ce que tu as un build propre que tu n'as pas une terachiée de conf par projet dans ton IDE. En vrac:

                      • Tout ce qui est coding style, error reporting, refactoring auto, templates (entre les projets internes, les upstreams, les open sourcés j'ai au moins 5 confs très différentes) etc.
                      • Tout ce qui de la conf ou pré-conf pour le lancement des tests dans l'IDE, remote debugging etc.
                      • Déploiement pour ceux qui aiment (moi pas)

                      Bref c'est quoi qui pète. .projet, .classpath, .settings ?

                      • [^] # Re: Améliorations surprenantes

                        Posté par  . Évalué à 3.

                        Tout ce qui est coding style

                        Ça je le gère via checkstyle.

                        error reporting, refactoring auto, templates (entre les projets internes, les upstreams, les open sourcés j'ai au moins 5 confs très différentes) etc.

                        J'en ai qu'un seul et ce n'est pas lié au projet.

                        Tout ce qui de la conf ou pré-conf pour le lancement des tests dans l'IDE, remote debugging etc.

                        Ça devrait être dans le pom.xml ou au moins automatisé mais surtout pas lié à l'IDE.

                        Déploiement pour ceux qui aiment (moi pas)

                        J'ai déjà pratiqué, toujours dans le pom.xml.

                        Bref c'est quoi qui pète. .projet, .classpath, .settings ?

                        Trop longtemps que je n'utilise plus ce genre de choses, mais ça venait des différences de configuration entre les développeurs d'un même projet. On se retrouvait souvent à se passer des bouts de conf' à la main (« Au fait avec mon dernier commit il faudra faire ça et ça dans eclipse. Quoi Tu l'a pas cette option !? »).

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: Améliorations surprenantes

                          Posté par  . Évalué à 4.

                          Ça je le gère via checkstyle.

                          Je ne te parle pas de vérifier, je te parle que l'IDE te produise par défaut du code répondant aux specs du projet. Tu ne vas pas t'amuser à réindenter pour le plaisir à chaque insertion. Genre j'ai un projet upstream où les gus aiment le old school illisible avec un Allman style en Java… Ou alors des mecs qui violent l'ordre des modifiers.

                          Après si tu commences à maintenir beaucoup de code, tu vas vite arriver à avoir des templates, des refactoring et des analyses un poil différentes.

                          Ça devrait être dans le pom.xml ou au moins automatisé mais surtout pas lié à l'IDE.

                          Ca dépend. Évidement que tu n'écris rien de spécifique à l'IDE pour exécuter ou déployer des tests. Maintenant quand tu passes ton temps à aller attacher des debugers sur des clusters distants dans des conditions à la con c'est pas ton build qui le fait, c'est pas son job. Selon ce sur quoi tu bosses tu as plus ou moins de glue dans l'IDE pour te permettre d'utiliser ce qui a été déployé.

                          Trop longtemps que je n'utilise plus ce genre de choses, mais ça venait des différences de configuration entre les développeurs d'un même projet. On se retrouvait souvent à se passer des bouts de conf' à la main

                          Effectivement gettho style, mauvais dev changer dev !

                          Je suis entièrement d'accord avec toi qu'un projet doit être IDE agnostic. Maintenant en tant que dev, si tu veux tirer parti de pas mal de fonctionalités, tu vas configurer tes environnements par projet pour t'aider au fur et à mesure à faire mieux, plus facilement, plus vite. Tu le retire ca n'a aucun impact sauf pour le dev.

                          • [^] # Re: Améliorations surprenantes

                            Posté par  (site web personnel) . Évalué à 3.

                            les gus aiment le old school illisible avec un Allman style en Java…

                            Quoi, on bosse dans la même boite ? ;-)

                            Bon ok, ici c'est pire, normalement du Allman c'est : 

                            while (x == y)
{
    something();
    somethingelse();
}

finalthing();

                            Ici la règle c'est :

                            while (x == y)
{
    something ();
    somethingelse ();
}

finalthing ();

                            Assez vomitif je trouve, surtout lorsque quelqu'un s'amuse à imbriquer les appels de fonctions :

                            obj1.setBla (obj2.getBla ());

                            • [^] # Re: Améliorations surprenantes

                              Posté par  . Évalué à 2.

                              J'avoue que ca me choque même plus comparé à perdre entre 2 et 3x plus de hauteur pour absolument rien. Sauf peut être le plaisir de rendre le code illisible vu que plus aucune fonction ne tient sur un écran vu qu'une pauvre boucle + if/else prendre déjàau moins 12 lignes…

                              Mais l'important c'est qu'au moins ca soit cohérent, les maintainer font les choix qu'ils veulent, même si ils sont mauvais ;) Si je suis pas content je fork…

                              Enfin dans tout les cas, si tu bosses sur des projets venant de plusieurs personnes/entités t'as toujours ce genre de conneries à gérer (+ template, + règle custom, + etc.).

                              • [^] # Commentaire supprimé

                                Posté par  . Évalué à 1.

                                Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Améliorations surprenantes

              Posté par  (site web personnel) . Évalué à 3.

              C'est justement Visual Studio 2012 qui devrait être capable de gérer du code explicitement compatible avec les anciennes versions de .Net et ASP.Net MVC. Mais d'après ce que j'ai compris c'est qu'il y a une p*tain de forte dépendance entre les versions de Windows, de IIS, de Asp.Net MVC, de Asp.Net, du .Net framework et de Visual Studio. Et quand tu veux changer de version de l'un faut tout upgrader. C'est une raivolution !

              L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

              • [^] # Re: Améliorations surprenantes

                Posté par  . Évalué à 2.

                Et oui il devrait mais ce n'est pas le cas. Alors ok c'est joli, cela peut etre ponctuellement pratique mais sur le long terme que c'est merdique. Je n'en reviens toujours pas qu'il ne soit pas possible de compiler un logiciel avec VS 2012 alors qu'il etait compilable avec VS 2010.

    • [^] # Re: Améliorations surprenantes

      Posté par  (site web personnel) . Évalué à 1.

      tu devrais regarder ce que netbeans, idea propose.

      eclipse devient de plus en plus lourd, ça me fait pensé au produit de rational rose…

      www.solutions-norenda.com

  • # Et netbeans ?

    Posté par  . Évalué à -3.

    Par rapport à la concurrence comme NetBeans ou Anjuta il se positionne où ?

    Si ma mémoire est bonne Code::blocks accepte aussi de faire du GTK mais là je ne suis pas certain.
    Quelqu'un pour confirmer ?

    • [^] # Re: Et netbeans ?

      Posté par  (site web personnel) . Évalué à 0.

      je préfère netbeans, je trouve le produit mieux peaufiné et mieux intégré.
      sans compté l'intégration de maven.

      niveau plugin, les meilleurs habituellement exisent

      j'aimerais bien pouvoir essayé buildr sous netbeans
      http://buildr.apache.org/

      www.solutions-norenda.com

  • # Performance

    Posté par  (site web personnel) . Évalué à 4.

    il parle un peu des performances

    j'espère qu'à ce niveau les problèmes de performance rencontré sous juno (beaucoup de thread sur le sujet son dispo) son enfin réglé.
    c'est ce qui me faisait rester sous indigo

    www.solutions-norenda.com

    • [^] # Re: Performance

      Posté par  (site web personnel) . Évalué à 1.

      Je n'ai pas lu grand chose là dessus, mais mes premiers tests sont plutôt optimistes !

      Je n'ai pas encore eu les lags de Juno et pourtant, j'ai monté une trentaine de projet avec plusieurs centaines de classes :)

      Mes 2 cents

      • [^] # Re: Performance

        Posté par  (site web personnel) . Évalué à 1.

        une petite recherche sur google
        juno performance problem
        et tu auras plein de page qui en parle

        il y a même une page sur le wiki
        http://wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation

        www.solutions-norenda.com

        • [^] # Re: Performance

          Posté par  . Évalué à 2.

          il y a même une page sur le wiki
          http://wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation

          D'ailleurs cette page indique que c'est résolu en grande partie depuis février et totalement avec kepler…

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Performance

            Posté par  (site web personnel) . Évalué à 2.

            sauf qu'on trouve aisément encore énormément de personne auquel ça n'a pas eu d'impact

            je suis retourné à indigo car c'était inutilisable

            www.solutions-norenda.com

            • [^] # Re: Performance

              Posté par  . Évalué à 2.

              Pareil pour moi.
              Je vais tester Eclipse 4.3 pour voir si c'est utilisable pour moi.

              Ça me rappelle la release d'Eclipse juste avant Indigo qui n'arrivait pas a passer pas les proxy d'entreprise :(
              J'ai du attendre la version majeure suivante avant de pouvoir upgrader.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 0.

            Ce commentaire a été supprimé par l’équipe de modération.

  • # Une plateforme, plus qu'un IDE

    Posté par  . Évalué à 3.

    Le problème d'Eclipse c'est que le projet s'est orienté a devenir une plateforme à tout faire, alors que Netbeans et ses concurrents se sont consacrés à devenir un IDE, c'est sans doute la raison pour laquelle Google a laissé tombé eclipse comme environnement officiel de développement pour Android au détriment d'intellij.
    Mais bon, en temps que bon geek on va tester avant de critique d'avantage :)

    • [^] # Re: Une plateforme, plus qu'un IDE

      Posté par  (site web personnel) . Évalué à 6.

      Pour Netbeans ce n'est pas tout à fait vrai vu que tout comme Eclipse, c'est aussi une plateforme pouvant servir de base à d'autres applications. Voir https://netbeans.org/features/platform/index.html et https://netbeans.org/features/platform/showcase.html

      Mais il est vrai qu'Eclipse est devenu une plateforme à tout faire et surtout n'importe quoi. IBM s'en sert même comme installeur (sic) pour ses produits ClearQuest & Co.

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Une plateforme, plus qu'un IDE

      Posté par  . Évalué à 3.

      Je pense qu'eclipse est une très bonne idée mal finie. L'idée était d'avoir quelque chose de très modulaire et d'utiliser OSGi pour ça. Dans les faits OSGi a mal était utilisé et ceux qui utilisent eclipse ont tendance à en utiliser un par projet avec pour chacun son set de plugin et sa configuration, alors qu'il s'agit bien d'un IDE multiprojet qui est censé gérer ça correctement (mais pas assez).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Une plateforme, plus qu'un IDE

      Posté par  . Évalué à 5.

      c'est sans doute la raison pour laquelle Google a laissé tombé eclipse comme environnement officiel de développement pour Android au détriment d'intellij.

      Soit il fallait lire "au profit d'Intellij", soit ça semble être plus un boulet qu'autre chose d'être l'IDE retenu par Google pour développer sur Android…

      • [^] # Re: Une plateforme, plus qu'un IDE

        Posté par  . Évalué à 2.

        soit ça semble être plus un boulet qu'autre chose d'être l'IDE retenu par Google pour développer sur Android…

        Je constate que Google choisi Eclipse, et paf Juno a des problèmes de performances. Google choisi IntelliJ, la version suivante d'Eclipse n'a plus de problèmes de performances. Coïncidence ?

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Une plateforme, plus qu'un IDE

          Posté par  . Évalué à 3.

          Ouai ils ont fait exprès de faire une release avec des régressions sur les perfs pour le fun. Et vu qu'android est leur seul marché, après s'être bien poilé ils ont fait une release sérieuse.

    • [^] # Re: Une plateforme, plus qu'un IDE

      Posté par  . Évalué à 8.

      J'en ai discute avec un membre de la communaute Eclipse.

      Son point de vue est que l'equipe d'Android Studio est tres fermee. Android etant lui meme un projet ferme avec un code drop de code libre apres chaque release.
      Le leader de l'equipe d'Android Studio se plaignait d'un certains nombre de bugs dans Eclipse, mais sans dire lesquels.
      La communaute Eclipse lui aurait propose de creer les bugs dans leur bugzilla, comme bon membre de la communaute, chose qu'il aurait promis de faire de maniere repetee.
      Ensuite, arrive l'annonce du switch d'Android Studio d'Eclipse vers IntelliJ.

      La communaute Eclipse est decue car le leader de l'Android Studio a n'a pas ete un bon membre de la communaute en denigrant Eclipse sans y contribuer et en ne tenant pas ses promesses.

      Je serais interesse par un retour de Google pourquoi ils ont fait le switch, mais vu la mentalite du responsable, il semble que cela n'arrivera jamais.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.