Eclipse WTP vs sydeo, «sert des modules sans publication»

103

J'ai le problème de trouver les performances du plugin sysdeo en utilisant le plugin intégré WTP d'Eclipse.

Pour faire la migration et donc la comparaison, j'ai installé les deux sur des projets séparés au sein d'éclipse.

J'ai remarqué une différence de productivité, d'après ce que j'ai compris: WTP a besoin de publier les sources dans un répertoire pour que Tomcat les ait à disposition. Ce "pulish" est long: il faut recharger le contexte pour que les modifications soient visibles. (5 sec dans la plupart des cours 15sec - 20sec dans le plus long).

Sysdeo no; il cible le répertoire eclipse par conséquent build internal dans le projet dès qu'une modification est faite par un fichier, eclipse build et ces modifications sont disponibles immédiatement (F5 sur le navigateur et nous avons le résultat immédiatement).

Voici ma configuration de serveur:

L'option "Sert les modules sans publication" permet de faire exactement ce qui fait sydeo: choisir le répertoire de construction du projet en cours d'exécution. Cette configuration s'exprime dans le fichier de contexte. (C'est pour pouvoir le récupérer que j'ai coché "Publier module les contextes pour séparer les lignes XML")

Comparaison de ces fichiers:

Voici le fichier de contexte à générer par sysdeo

< Context path="/tatoile _syseo" reloadable="false" docBase="D:\32bit\serveur32bit\workspace\tatoile _syseo" workDir="D:\32bit\serveur32bit\workspace\tatoile _syseo\work" />

Le contexte de fichier à générer par WTP

<? xml version = "1.0" encoding = "UTF-8"?> <Contexte docBase = "D: \ 32bit \ serveur32bit \ workspace \ tatoile \ web" path = "/ tatoile" reloadable = "true" source = "org .eclipse.jst.jee.server: tatoile "> <Resources className =" org.eclipse.jst.server.tomcat.loader.WtpDirContext "extraResourcePaths =" / WEB-INF / classes | D: \ 32bit \ serveur32bit \ workspace \ tatoile \ build \ classes "virtualClasspath =" D: \ 32bit \ serveur32bit \ workspace \ tatoile \ build \ classes "/> <Loader className =" org.eclipse.jst.server.tomcat.loader.WtpWebappLoader "useSystemClassLoaderAsParent =" false " virtualClasspath = "D: \ 32bit \ serveur32bit \ workspace \ tatoile \ build \ classes" /> <JarScanner scanAllDirectories = "true" /> </ Context>

Plus tard, analyser ces deux fichiers se ressemble.

Revenons maintenant au problème. J'utilise le même serveur, par conséquent les deux fichiers de contexte ci-dessus sont définis pour celui-ci. Expérience: je lance le tomcat par le plugin sysdeo, les charges dans deux contextes se font l'un pour configurer façon WTP l'autre par sysdeo. Les deux autorités réagissent de la même manière, les modifications sont immédiates dans tatoile _syseo et tatoile.

Par contre, je lance tomcat via le plugin WTP (tab server etc.) dans eclipse, les modifications ne sont pas immédiatement apportées dans les deux projets tatoile _syseo et tatoile. Remarque: le rechargement automatique doit obligatoirement être mis en Activé pour que les modifications soient prises en compte. (Lorsque le serveur nous indique qu'il a rechargé le contexte, nous pouvons voir les modifications.)

entrez la description de l'image ici

J'en déduis que la configuration des contextes n'est pas la raison, mais plutôt la façon dont le plugin lance tomcat; et là ou je sèche…

Voici le projet WTP:

entrez la description de l'image ici

— Vsplit
source

Avez-vous un problème sur Sysdeo ou WTP? OTOH Bien sûr, WTP aura besoin de plus de temps pour les modifications car voici ce qu'il fera pour republier: (1) build classes (2) annulation du déploiement de l'ancienne application web (3) copie du résultat de la build dans le dossier de déploiement de tomcat (4) tomcat démarrera automatiquement le app. Pendant ce temps, avec sysdeo, les classes en RAM sont modifiées à la volée dès qu'il y a des changements effectués (identifiés par une nouvelle date dans tous les fichiers de classes). Ensuite, il y a certaines limitations de modifications qui ne peuvent pas être apportées à la volée (lorsque vous ajoutez de nouvelles méthodes, la structure de classe a également changé), dans ce cas, cela donnera un avertissement.

J'ai utilisé à la fois Sysdeo et WTP sur le même projet. La différence la plus significative que j'ai remarquée était que la configuration de Sysdeo me paraissait plus facile, mais cela pourrait être biaisé.

— Markus

Le problème a été résolu en ajoutant MAVEN avec le déploiement WTP. Aucun problème de performances. Aucun problème de performances et je

— n'active

Si vous avez résolu le problème, pouvez-vous publier une réponse?

— Anubian Noob

@AnubianNoob oui quand je l'ai expliqué dans mon précédent post. J'ai résolu le problème en utilisant la configuration maven.

— Vsplit

La réponse citée de @Vsplit

Le problème a été résolu en ajoutant MAVEN avec le déploiement WTP. Aucun problème de performances ... et je n'active pas les modules de service sans publication

— Marko
source

-1 Ce n'est pas une réponse. veuillez ajouter la réponse avec plus de détails.

— Isaac G Sivaa

Bonjour, je suis désolé pour ma réponse tardive. Mais comme vous devez le remarquer, je ne peux pas résoudre le problème du plugin Sysdeo. Mais j'utilise le plugin Maven avec le déploiement WTP. Vous pouvez voir cet exemple de tutoriel youtube.com/watch?v=YeC7XQho-O0

— Vsplit

recherchez sur le marché des plugins un plugin gratuit appelé m2e-wtp. Cela prendra en charge les problèmes de portée fournis. En ce qui concerne les classes non déployées, les endroits habituels que je regarde sont l'assembly de déploiement et / ou Java Build Path. Assurez-vous que les entrées (et les modules dépendants) sont toutes là et situées au bon endroit.

— Shrinidhi Krishnakumar
source