Bonjour,
dans le cadre de la migration de quelques postes bureautique de windows
à Linux (Kubuntu 6.0.6), il me faut migrer des développeurs java qui
disposent actuellement de :
- eclipse 3.1
- Plugin tomcat sysdeo
- Tomcat 5
J'ai donc installé eclipse sur un poste linux, ça fonctionne sans
problème. Mais la suite m'est plus difficile.
Comme tout admnistrateur Unix qui se respecte, je ne désire pas que mes
développeur installe eux-même des applications ou des plug-ins dans les
répertoire système (ils peuvent faire ce qu'ils veulent dans leur home
directory). Je pense avoir réglé ce problème avec la création d'un
repertoire .eclipse dans leurs répertoire.
Maintenant je voudrais éviter de leur installer un tomcat sur chacun de
leurs postes (ce que je ne trouve pas très maintenable ni sécurisé).
Mais je n'arrive pas à trouver de documentation décrivant ce genre
d'architecture. En effet, tous les documents que je trouve sur éclipse
et ses plugins parlent de chemin du style C:\Tomcat et d'une
installation d'un serveur Tomcat en local.
Serais-je le seul à vouloir que les développeurs travaillent sur des
postes Linux ? Suis-je obliger de gérer autant d'installation de Tomcat
que de développeur ? Y-a-t-il quelqu'un qui travaille de cette manière :
- Un Eclipse sur chaque poste linux développeur
- Un serveur CVS/Subversion pour gérer leurs développement
- Un serveur Tomcat de développement commun
- Un serveur Tomcat de production (innacessible au développeur)
Merci de m'indiquer des réferences de documents/sites/livres qui
abordent ces sujets, car actuellement mes développeurs ne veulent pas
envisager de migrer s'il n'y trouve que des inconvénients (Ce que je
peux comprendre).
A condition de pas avoir 250 développeurs a mon avis
Et pourquoi pas? les applis web sont toutes isolées
Ben t'as intéret a avoir un très très gros serveur dans ce cas. De plus tu ne pourra pas faire de debug pas a pas.
Même avec un très gros serveur, la JVM ne sait pas gérer la mémoire au delà d'une certaine limite... Cela ne sert à rien de lui en allouer plus, car elle sera incapable de l'utiliser.
-- David Jourand
A condition de pas avoir 250 développeurs a mon avis
Et pourquoi pas? les applis web sont toutes isolées
Ben t'as intéret a avoir un très très gros serveur dans ce cas.
De plus tu ne pourra pas faire de debug pas a pas.
Même avec un très gros serveur, la JVM ne sait pas gérer la mémoire au
delà d'une certaine limite... Cela ne sert à rien de lui en allouer
plus, car elle sera incapable de l'utiliser.
A condition de pas avoir 250 développeurs a mon avis
Et pourquoi pas? les applis web sont toutes isolées
Ben t'as intéret a avoir un très très gros serveur dans ce cas. De plus tu ne pourra pas faire de debug pas a pas.
Même avec un très gros serveur, la JVM ne sait pas gérer la mémoire au delà d'une certaine limite... Cela ne sert à rien de lui en allouer plus, car elle sera incapable de l'utiliser.
-- David Jourand
Cédric Chabanois
babor wrote:
1 tomcat mais une application web pour chaque développeur ne devrait pas poser de problème. La console web de management de Tomcat permet à chaque développeur de redéployer son appli web sans gêner les autres.
C'est ce que nous faisons et ça ne pose pas de problème.
Bizarre car de mon côté, j'ai parfois besoin de relancer Tomcat, relancer l'appli web ne suffit pas toujours (bug de Tomcat, de l'appli ?). D'autre part, il m'arrive d'avoir à modifier le fichier de configuration xml du contexte de mon application (référence à une BDD...) et je ne crois pas que le redémarrage de l'appli web prenne en compte les modifs.
Maintenant je travaille sur une nouvelle appli web qui utilise une librairie en C, donc là le redémarrage de Tomcat s'impose systématiquement.
Et pour le debuggage tu fais comment ? Je crois bien qu'un breakpoint ne suspend que le thread concerné mais quand même je me demande bien ce que plusieurs debuggages simultanés peuvent donner, sans compter que lors d'un debuggage à priori rien n'empêche l'utilisateur d'arrêter carrément Tomcat volontairement ou non ...
En fait moi je serai plutôt pour un serveur tomcat / poste / utilisateur. Et chacun se débrouille avec son propre Tomcat qu'il maintient lui-même. En principe un développeur n'est pas neuneu et devrait savoir se débrouiller avec Tomcat, quitte à fournir un peu de doc et une préconfiguration.
Ca me parait plus courant comme façon de faire et moins problématique. Cela rend aussi les développeurs plus autonome, il faut arrêter d'être aussi paternaliste ("mes développeurs" !)
J'irai plus loin, un développeur n'est pas une secrétaire et devrait gérer lui-même sa machine même si on peut mettre en place des recommandations ou une préconfiguration.
Pour le serveur de prod, c'est bien sûr autre chose ...
Cédric
babor wrote:
1 tomcat mais une application web pour chaque développeur ne devrait pas
poser de problème.
La console web de management de Tomcat permet à chaque développeur de
redéployer son appli web sans gêner les autres.
C'est ce que nous faisons et ça ne pose pas de problème.
Bizarre car de mon côté, j'ai parfois besoin de relancer Tomcat,
relancer l'appli web ne suffit pas toujours (bug de Tomcat, de l'appli
?). D'autre part, il m'arrive d'avoir à modifier le fichier de
configuration xml du contexte de mon application (référence à une
BDD...) et je ne crois pas que le redémarrage de l'appli web prenne en
compte les modifs.
Maintenant je travaille sur une nouvelle appli web qui utilise une
librairie en C, donc là le redémarrage de Tomcat s'impose systématiquement.
Et pour le debuggage tu fais comment ? Je crois bien qu'un breakpoint ne
suspend que le thread concerné mais quand même je me demande bien ce que
plusieurs debuggages simultanés peuvent donner, sans compter que lors
d'un debuggage à priori rien n'empêche l'utilisateur d'arrêter carrément
Tomcat volontairement ou non ...
En fait moi je serai plutôt pour un serveur tomcat / poste /
utilisateur. Et chacun se débrouille avec son propre Tomcat qu'il
maintient lui-même. En principe un développeur n'est pas neuneu et
devrait savoir se débrouiller avec Tomcat, quitte à fournir un peu de
doc et une préconfiguration.
Ca me parait plus courant comme façon de faire et moins problématique.
Cela rend aussi les développeurs plus autonome, il faut arrêter d'être
aussi paternaliste ("mes développeurs" !)
J'irai plus loin, un développeur n'est pas une secrétaire et devrait
gérer lui-même sa machine même si on peut mettre en place des
recommandations ou une préconfiguration.
Pour le serveur de prod, c'est bien sûr autre chose ...
1 tomcat mais une application web pour chaque développeur ne devrait pas poser de problème. La console web de management de Tomcat permet à chaque développeur de redéployer son appli web sans gêner les autres.
C'est ce que nous faisons et ça ne pose pas de problème.
Bizarre car de mon côté, j'ai parfois besoin de relancer Tomcat, relancer l'appli web ne suffit pas toujours (bug de Tomcat, de l'appli ?). D'autre part, il m'arrive d'avoir à modifier le fichier de configuration xml du contexte de mon application (référence à une BDD...) et je ne crois pas que le redémarrage de l'appli web prenne en compte les modifs.
Maintenant je travaille sur une nouvelle appli web qui utilise une librairie en C, donc là le redémarrage de Tomcat s'impose systématiquement.
Et pour le debuggage tu fais comment ? Je crois bien qu'un breakpoint ne suspend que le thread concerné mais quand même je me demande bien ce que plusieurs debuggages simultanés peuvent donner, sans compter que lors d'un debuggage à priori rien n'empêche l'utilisateur d'arrêter carrément Tomcat volontairement ou non ...
En fait moi je serai plutôt pour un serveur tomcat / poste / utilisateur. Et chacun se débrouille avec son propre Tomcat qu'il maintient lui-même. En principe un développeur n'est pas neuneu et devrait savoir se débrouiller avec Tomcat, quitte à fournir un peu de doc et une préconfiguration.
Ca me parait plus courant comme façon de faire et moins problématique. Cela rend aussi les développeurs plus autonome, il faut arrêter d'être aussi paternaliste ("mes développeurs" !)
J'irai plus loin, un développeur n'est pas une secrétaire et devrait gérer lui-même sa machine même si on peut mettre en place des recommandations ou une préconfiguration.
Pour le serveur de prod, c'est bien sûr autre chose ...
