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).
... - Un serveur Tomcat de développement commun ...
A mon avis, il faut un Tomcat par développeur afin qu'ils puissent débugger avant de poster leurs créations ...
Sans parler s'il développent des classes ou des servlet s'ils doivent relancer l'appli tomcat a chaque fois
babor
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.
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.
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.
Kupee
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.
A condition de pas avoir 250 développeurs a mon avis
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.
A condition de pas avoir 250 développeurs a mon avis
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.
A condition de pas avoir 250 développeurs a mon avis
babor
A condition de pas avoir 250 développeurs a mon avis
Et pourquoi pas? les applis web sont toutes isolées
A condition de pas avoir 250 développeurs a mon avis
Et pourquoi pas? les applis web sont toutes isolées
A condition de pas avoir 250 développeurs a mon avis
Et pourquoi pas? les applis web sont toutes isolées
Jaypee
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).
Merci d'avance. Bonjour,
Si le but est de mutualiser au maximum, je pense qu'il manque une ou deux instances de Tomcat : +1 serveur qui duplique la version de production et sert : - de backup en cas de panne sévère de la production. - à reproduire les bugs pour le support. - de machine de "reporting" pour faire tourner les stats sans charger la production.
+1 éventuellement pour l'intégration. Le serveur de développement peut servir à çà avec des "sandboxes", l' idée est qu'il faut laisser les mains libres aux développeurs de tenter des trucs, sans que que le résultats soit une usine à gaz permanente. Le serveur d'intégration tourne les versions stables du moment.
J-P
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).
Merci d'avance.
Bonjour,
Si le but est de mutualiser au maximum, je pense qu'il manque une ou
deux instances de Tomcat :
+1 serveur qui duplique la version de production et sert :
- de backup en cas de panne sévère de la production.
- à reproduire les bugs pour le support.
- de machine de "reporting" pour faire tourner les stats sans charger la
production.
+1 éventuellement pour l'intégration. Le serveur de développement
peut servir à çà avec des "sandboxes", l' idée est qu'il faut
laisser les mains libres aux développeurs de tenter des trucs, sans que
que le résultats soit une usine à gaz permanente. Le serveur
d'intégration tourne les versions stables du moment.
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).
Merci d'avance. Bonjour,
Si le but est de mutualiser au maximum, je pense qu'il manque une ou deux instances de Tomcat : +1 serveur qui duplique la version de production et sert : - de backup en cas de panne sévère de la production. - à reproduire les bugs pour le support. - de machine de "reporting" pour faire tourner les stats sans charger la production.
+1 éventuellement pour l'intégration. Le serveur de développement peut servir à çà avec des "sandboxes", l' idée est qu'il faut laisser les mains libres aux développeurs de tenter des trucs, sans que que le résultats soit une usine à gaz permanente. Le serveur d'intégration tourne les versions stables du moment.
J-P
Marc SIRAMY
Kupee 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.
A condition de pas avoir 250 développeurs a mon avis
Oui mais cela oblige justement chaque développeur à passer par la console web de management pour déployer son application.
De fait, le déploiement peut il encore être automatisé, via ant par exemple ? Cela doit être faisable en attribuant un nom d'application par développeur.
De plus, j'imagine mal 250 versions de la même appli déployées sur un même tomcat. Et la nécessité de redémarrer le serveur pour effectuer certains déploiements peut encore compliquer les choses.
-- Marc
Kupee 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.
A condition de pas avoir 250 développeurs a mon avis
Oui mais cela oblige justement chaque développeur à passer par la
console web de management pour déployer son application.
De fait, le déploiement peut il encore être automatisé, via ant par
exemple ?
Cela doit être faisable en attribuant un nom d'application par développeur.
De plus, j'imagine mal 250 versions de la même appli déployées sur un
même tomcat. Et la nécessité de redémarrer le serveur pour effectuer
certains déploiements peut encore compliquer les choses.
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.
A condition de pas avoir 250 développeurs a mon avis
Oui mais cela oblige justement chaque développeur à passer par la console web de management pour déployer son application.
De fait, le déploiement peut il encore être automatisé, via ant par exemple ? Cela doit être faisable en attribuant un nom d'application par développeur.
De plus, j'imagine mal 250 versions de la même appli déployées sur un même tomcat. Et la nécessité de redémarrer le serveur pour effectuer certains déploiements peut encore compliquer les choses.
-- Marc
David JOURAND
1 tomcat mais une application web pour chaque développeur ne devrait pas poser de problème.
A condition de pas avoir 250 développeurs a mon avis
Oui mais cela oblige justement chaque développeur à passer par la console web de management pour déployer son application.
De plus, j'imagine mal 250 versions de la même appli déployées sur un même tomcat. Et la nécessité de redémarrer le serveur pour effectuer certains déploiements peut encore compliquer les choses.
Sans compter l'occupation mémoire... La JVM connait des limites !
-- David Jourand
1 tomcat mais une application web pour chaque développeur ne devrait
pas poser de problème.
A condition de pas avoir 250 développeurs a mon avis
Oui mais cela oblige justement chaque développeur à passer par la
console web de management pour déployer son application.
De plus, j'imagine mal 250 versions de la même appli déployées sur un
même tomcat. Et la nécessité de redémarrer le serveur pour effectuer
certains déploiements peut encore compliquer les choses.
Sans compter l'occupation mémoire... La JVM connait des limites !
1 tomcat mais une application web pour chaque développeur ne devrait pas poser de problème.
A condition de pas avoir 250 développeurs a mon avis
Oui mais cela oblige justement chaque développeur à passer par la console web de management pour déployer son application.
De plus, j'imagine mal 250 versions de la même appli déployées sur un même tomcat. Et la nécessité de redémarrer le serveur pour effectuer certains déploiements peut encore compliquer les choses.
Sans compter l'occupation mémoire... La JVM connait des limites !
-- David Jourand
Kupee
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.
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.
