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

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

Pour effectuer la migration et donc la comparaison, j’ai installé les deux sur des projets distincts au sein d’eclipse.

J’ai remarqué une différence de productivité, selon ce que j’ai compris: WTP doit publier des sources dans un répertoire afin que tomcat puisse les disposer. Ce “pulish” est long: il faut recharger le contexte pour que les modifications soient visibles. (5 secs dans la plupart des sortingage 15sec – 20sec le plus long).

Sysdeo no; il cible du répertoire eclipse par conséquent construit en interne 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 “Serves 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
 
  • Le contexte de fichier à générer par WTP

Plus tard, parsingr ces deux fichiers est identique.

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 sont faites pour configurer de manière WTP l’autre par sysdeo. Les deux autorités réagissent de la même manière, les modifications sont immédiates dans le tacanvas _syseo et le tacanvas.

Par contre, je lance tomcat via le plugin WTP (tab server etc.) en eclipse, les modifications ne sont pas faites immédiatement dans les deux projets tacanvas _syseo et tacanvas. Remarque: le rechargement automatique doit nécessairement être activé pour que les modifications soient sockets en compte. (Lorsque le serveur nous indique qu’il a rechargé le contexte, nous pouvons voir les modifications.)

entrer la description de l'image ici

Je 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:

entrer la description de l'image ici

La réponse citée de @Vsplit

Le problème a été résolu en ajoutant MAVEN avec le déploiement WTP. Pas de problèmes de performance … et je n’active pas les modules de service sans publication

chercher dans le marché des plugins un plugin gratuit appelé m2e-wtp. Cela prendra en charge les problèmes de scope fournis. En ce qui concerne les classes qui ne sont pas déployées, les emplacements habituels sont l’assemblage de déploiement et / ou le chemin de génération Java. Assurez-vous que les entrées (et les modules dépendants) sont tous là et situés au bon endroit.