Discussion :

[gifffftane]

Les progrès de Netbeans poussent les frontières... et lorsque d'autres, tel Groovy, progressent aussi, alors chacun est conduit à revoir ou redéfinir ses positions.

Groovy est l'un des langages qui animent le plus les listes et forum de discussion Netbeans (le premier, mis à part Java, étant le PHP).

Souvent, quelqu'un intervient pour dire Je n'arrive pas à faire fonctionner telle chose avec Groovy sur Netbeans, pourquoi ? (par exemple : Maven & Grails support together in Netbeans 6.7). Et quelqu'un de l'équipe de développement de Netbeans, lui répond que c'est vrai, mais qu'il y a un patch, ou une nouvelle version, ou qu'il faut faire une demande en ce sens, et que le problème sera résolu.

Et c'est ce qui arrive : le support de groovy progresse, et devient aujourd'hui presque correct. Coloration syntaxique, auto-complétion, lancement de script groovy, etc, fonctionnent à peu près.

Les équipes de Netbeans suivent la demande sans la précéder, à l'exception notable de Geertjan, qui a consacré plusieurs articles à décrire comment utiliser Groovy avec Netbeans : Significant Productivity Gains with Grails? ou How Groovy Helps JavaFX: Farewell Pure Java Code? parmi les derniers.

Les débats sont souvent plus animés sur la liste de groovy, ce qui est étonnant puisque rien, à priori, ne pousse les développeurs Groovy a utiliser Netbeans : si l'on regarde la documentation officielle de Groovy, pas moins de 18 pages sont consacrées à Eclipse, contre une seule à Netbeans.

Et ce qui peut pousser quelqu'un à intervenir sur une liste Groovy pour affirmer que Netbeans 6.7 est moins bon que... Emacs, relève des mystères propres à la profession d'informaticien, mais c'est ce qui s'est produit. Et c'est ainsi qu'en plein 21 siècle, dans le forum d'un des langages les plus modernes et dynamiques qui soit, le débat Vim/Emacs a rejailli.

Aussitôt suivi par un débat sur les tests JUnit/TestNG (quelqu'un ne parvient pas à exécuter un test avec Netbeans ce qui, on le comprend, justifie un rejet de Netbeans), aussitôt suivi par un débat sur la situation financière de Sun, etc.

Les principaux acteurs du monde Groovy sont intervenus pour rappeler avec insistance l'excellence des rapports Groovy/Eclipse, sans jamais écrire le mot Netbeans, et pour rappeler, cela vaut mieux, que Groovy fonctionne très bien tant avec JUnit que avec Test NG.

Derrière Netbeans il y a Sun bien sûr, et donc l'ombre d'Oracle. Et derrière Groovy il y a déjà SpringSource, et tout ceux qui souhaitent que le monde Java prenne de l'indépendance par rapport à Sun.

Le couple improbable Netbeans/Groovy sera-t-il le couple de la raison ?

[Uther]

Je pense qu'il y a probablement une notion de politique là dedans, mais je pense qu'il s'agit avant tout du besoin de faire un choix, car il est plus facile de supporter une plateforme que plusieurs.

Éclipse à longtemps été le leader incontesté et du coup a été adopté de facto, par pas mal de sociétés. Il se retrouve un peu dans la position d'IE : tout est d'abord fait pour lui et si les gens veulent quelque-chose d'autre, on les laisse se débrouiller.

[Sharpounet]

Si je peux ajouter un commentaire malgré ma récente inscription sur le forum,
je dirais que je suis assez mitigé sur Netbeans et son évolution...

D'un côté, Netbeans m'apparait comme un super EDI pour développer du Java et d'un autre, le fait qu'il se diversifie à ce point sur d'autres choses me chagrine un peu. Sans vouloir relancer l'éternel débat, j'ai peur qu'il devienne aussi usine à gaz que peut l'être un Eclipse bourré de plugins...

Ceci dit, l'évolution actuelle montre bien que des gros projets se développent sur plusieurs plateformes (un front office type web et le back office en Java par exemple) et les EDI suivent donc le mouvement naturellement... J'ai juste peur que ça devienne tellement diversifié qu'on ne l'oublie pour un EDI plus recentré sur un langage particulier...

[gifffftane]

Il y a deux choses, je pense : les syntaxes utiles directement dans les projets java (XML, HTML, JSP, Javascript...), et les syntaxes pour programmeurs que Sun voudrait séduire (PHP).

Tout cela transforme Netbeans en une sorte d'EDI généralisé, que Sun utilise ensuite pour placer ses pions (projet KenaÏ).

La démarche est exactement la même pour Eclipse, sauf que au lieu d'un seul acteur il y a un consortium.

Pour nous qui développons des projets qui n'ont pas forcément grand chose à voir avec les intérêts du consortium lambda, cela nous arrange d'avoir des EDI capables de gérer plusieurs langages : **MOI**, par exemple, dans n'importe quel projet java, j'ai Maven, Spring, Ant... et cela explose dès qu'on parle de web.

D'où mon intérêt pour des choses comme Groovy, qui se place sur la notion de langage métier ou DSL... même si je n'imagine pas (et ne veux pas) qu'il remplace tout, j'espère que c'est plus facile de lier tous ces trucs dont on a besoin.

println "Peut être ? "

[gifffftane]

Un nouvel article de Geertjan concernant groovy, cette fois ci sur Griffon, un système de GUI Groovy/Swing : Java Store Support for Griffon in NetBeans IDE 6.7.1.

[madfu]

Des news sur l'avancée du développement de Griffon ou un depot officiel du projet ?

[fb314]

depuis la version 6.8 de netbeans, le module groovy est nativement intégré dans l'IDE.
En ce qui me concerne, j'ai toujours trouvé plus facile d'utiliser groovy dans netbeans que dans eclipse.