Discussion :

[Cyborg]

Bonjour à tous,

Sous Eclipse, nous sommes donc 4 à passer un temps monstre à installer / configurer / tester / installer / tester / re-pester / ...

Question : comment fait-on pour programmer efficacement en JEE, sans passer des journées à installer des plugins et autres .jar qui ne veulent jamais fonctionner ?

Nous nous sommes éclaté avec du JDBC, des servlets, du JSP, mêlé de JQuery, d'Ajax et de CSS. Aucun soucis. Nous sommes passé à l'utilisation de Frameworks, et là ... c'est le drame !!

Donc il y a certainement une méthode de travail qu'on a zappé. Vous faites comment ?

Maven fait aussi partie de ces plugins avec lequel on a quelques difficultés, donc n'hésitez pas ! Tous les conseils sont les bienvenus !

Merci d'avance pour votre aide.

Edit 1 :
On a réussi à faire marcher Maven, donc on va voir ce que ça donne... Si ça résout nos problèmes...

Edit 2 :
Petite correction, nous avions réussi à l'installer mais nous n'arrivons pas à le faire fonctionner...

Donc toute idée, quel que soit le sujet, on est preneur en fait.

[Jimmy_]

Nous nous sommes éclaté avec du JDBC, des servlets, du JSP, mêlé de JQuery, d'Ajax et de CSS. Aucun soucis. Nous sommes passé à l'utilisation de Frameworks, et là ... c'est le drame !!

La plupart du temps en entreprise il y a une équipe dédié à ça.
Son rôle est de fournir un poste de travail développeur opérationnel immédiatement, avec tout ce qui va bien comme par exemple des squelettes d'applications et des plugins maison pour générer une partie du code.

Faire du maven pour faire du maven car les copains en fond, c'est inutile, le besoin dicte l'utilisation de tel ou tel outil.
Spring ce n'est pas le plus simple des frameworks et la roadmap du projet convient de moins en moins aux grosses boites. Mais ici je vais me faire tapper dessus en disant ça. Mais c'est une réalité, j'ai un gros client (genre une boite du CAC40) qui a déclaré Spring persona non grata dans son SI.

Depuis des années, la tendance a été d'empiler les couches les unes sur les autres, et au final le ticket d'entrée du développeur était de plus en plus cher. On a finit par mettre tout ça en centre de service, mais là encore le résultat est une augmentation des coûts. Maintenant il faut développer pour tous les types d'écrans, internet, smartphones, tablettes etc ... on multiplie encore les technos et donc les coûts. Les développeurs mettent des mois et des mois avant d'être opérationnel, là ou quelques jours suffisait.

La tendance à l'heure actuelle est donc de simplifier tout ça.

[Cyborg]

Si vous voulez un environnement J2EE configuré pour du spring, téléchargez directement spring source en bundle, ca vous évitera de perdre du temps :p

Et y'a la même chose pour hibernate, struts ?
On nous demande d'apprendre à manipuler différents frameworks. On va pas utiliser un nouvel EDI pour chaque framework ?!?

La plupart du temps en entreprise il y a une équipe dédié à ça.
Son rôle est de fournir un poste de travail développeur opérationnel immédiatement, avec tout ce qui va bien comme par exemple des squelettes d'applications et des plugins maison pour générer une partie du code.

Comme j'le disais, on est actuellement en "formation" (on s'auto-forme plus qu'autre chose) pour apprendre à manipuler ces différents Frameworks chez les clients. Si on peut pas les installer, pas facile d'apprendre à les manipuler.

Faire du maven pour faire du maven car les copains en fond, c'est inutile, le besoin dicte l'utilisation de tel ou tel outil.

Si ça peut nous simplifier la vie pour l'install de nos postes, on est preneur.

Spring ce n'est pas le plus simple des frameworks et la roadmap du projet convient de moins en moins aux grosses boites.

En l'occurrence, c'est ce qu'on nous demande d'apprendre. C'est pas à nous de dire si c'est bien, ou pas.

Depuis des années, la tendance a été d'empiler les couches les unes sur les autres [...]. Maintenant il faut développer pour tous les types d'écrans, internet, smartphones, tablettes etc ...[...]

C'est un débat à part entière, donc on va essayer d'éviter. Cependant, y'a quand même une question qui me turlupine :
Comment un développement en plusieurs couches, optimisant les parties de code réutilisables, peut coûter plus cher qu'un développement où, pour chaque matériel, il faut tout re-développer ?
Re-développer tout de manière plus spécifique est moins coûteux que de développer une bonne fois pour toute de manière générique ?

L'exemple des smartphones, tables, etc me parait le plus parlant : il n'y a que l'interface à revoir, en fonction du matériel ; le contenu du logiciel, le coeur métier, les accès en base de données ... Tout ça n'est pas à re-développer !?!

[tchize_]

hibernate, doit y a avoir des plugins principalement pour gérer l'autocomplétion dans les fichiers. J'en ai jamais vraiment ressenti le besoin.
Struts, je vois pas trop quel serait le role des plugins là dedans C'est surtout des classes java et un peu de xml.
Spring IOC est un très bon outils que je regrette de ne pas avoir découvert plus tôt pour mon dev, ca fait économiser moulte lignes de code. Maintenant, les trucs comme spring web etc, c'est plus spécifique et je comprend que toutes les boites n'en veillent pas nécessairement.

L'empilement de couche n'est pas trop un problème, ce qui pose problème c'est quand on passe à l'orgie de couche où toute modification nécessite presque de modifier 7 ou huit couches différentes Et il faut dire ce qui est les "architectes" java ont fait beaucoup de dégats de ce coté là en créant d'énormes structure domino impossibles à maintenir à coût raisonnable.
Il ne faut jamais penser "développer générique", il faut penser "développer pour le buisness, rendre par la suite le code générique si le besoin le justifie". Rien ne sert de développer client/serveur avec des couche d'abstraction interrogées par le web si au final le client a juste besoin d'une connexion desktop et ne budgetise pas au final le smartphone, l'iphone et la tablette

Quand à l'équipe dédiée pour vous donner un pose de travail dev, c'est peut-être vrai dans les grosses SSI qui vendent 50 développeurs temps plein, mais les endroits comme là où je bosse ou t'as juste une équipe de dev en appoint parce que le dev c'est pas le buisness de la boite, on se débrouille