java - Eclipse WTP vs sydeo, "sirve módulos sin publicar"
tomcat eclipse-wtp (2)
La respuesta citada de @Vsplit
El problema se resolvió agregando MAVEN con la implementación de WTP. Sin problemas de rendimiento ... y no activo módulos de servicio sin publicar
Tengo el problema de encontrar las prestaciones del plugin sysdeo utilizando el plugin integrado WTP of eclipse.
Para hacer la migración y, por lo tanto, la comparación, instalé ambos en proyectos separados dentro de Eclipse.
Observé una diferencia de productividad, de acuerdo con lo que entendí: WTP necesita publicar fuentes en una compilación de directorio para que tomcat las tenga en el acuerdo. Este "pulido" es largo: necesita la recarga del contexto para que las modificaciones sean visibles. (5 secos en la mayoría de los jardines 15 segundos - 20 segundos en los más largos).
Sysdeo no; se dirige al eclipse del directorio, consecuentemente se construye internamente en el proyecto tan pronto como se realiza una modificación por un archivo, eclipse build y estas modificaciones están disponibles inmediatamente (F5 en el navegador y tenemos el resultado inmediatamente).
Aquí está mi configuración de servidor:
La opción "Sirve módulos sin publicar" permite hacer exactamente lo que hace que sydeo: elija el directorio de compilación del proyecto en ejecución. Esta configuración se expresa en el archivo de contexto. (Es para poder recuperarlo lo que he marcado "Publicar modula contextos para separar filas XML")
Comparación de estos archivos:
- Aquí está el archivo de contexto para generar por sysdeo
< Context path="/tatoile _syseo" reloadable="false" docBase="D:/32bit/serveur32bit/workspace/tatoile _syseo" workDir="D:/32bit/serveur32bit/workspace/tatoile _syseo/work" />
- El contexto del archivo para generar por WTP
<? xml version = "1.0" encoding = "UTF-8"?> <Contexto docBase = "D: / 32bit / serveur32bit / workspace / tatoile / web" ruta = "/ 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>
Más tarde analizar esos dos archivos es similar.
Ahora volvamos al problema. Utilizo el mismo servidor, por lo tanto, los dos archivos de contexto de arriba están definidos para este. Experiencia: Lanzo el tomcat por el plugin sysdeo, las cargas en dos contexto se hacen para configurar el modo WTP el otro por sysdeo. Ambas autoridades reaccionan de la misma manera, las modificaciones son inmediatas en tatoile _syseo y tatoile.
Por otro lado, lanzo tomcat a través del plugin WTP (servidor de pestañas, etc.) en eclipse, las modificaciones no se hacen inmediatamente en los dos proyectos _syseo y tatoile. Nota: La recarga automática debe estar necesariamente habilitada para que las modificaciones se tengan en cuenta. (Cuando el servidor nos indica que ha vuelto a cargar el contexto, podemos ver las modificaciones).
Deduzco que la configuración de contextos no es la razón, sino la forma en que el complemento se inicia tomcat; y allí o yo seco ...
Aquí está el proyecto WTP:
busca en el mercado de complementos un plugin gratuito llamado m2e-wtp. Eso se ocupará de los problemas de alcance proporcionados. En cuanto a las clases que no se implementan, los lugares habituales que miro son el ensamblaje de implementación y / o la ruta de compilación de Java. Asegúrese de que las entradas (y los módulos dependientes) estén todos allí y ubicados en el lugar correcto.