java - que - maven tutorial español
Cómo expresar dependencias entre proyectos en Eclipse PDE (8)
Nunca lo hice, así que este es un enfoque teórico. Pero probaría un sistema de administración de dependencias como ivy o maven2.
Como maven2 hace mucho más, entonces solo gestión de la dependencia, recomendaría ivy en este caso.
Estoy buscando la mejor práctica de manejar las dependencias interproyectos entre tipos de proyectos mixtos donde algunos de los proyectos son proyectos eclipse plug-in / OSGI bundle (una aplicación RCP) y otros son simplemente viejos proyectos java (módulos de servicios web). Pocos de los complementos eclipse tienen dependencias en proyectos Java.
Mi problema es que, al menos por lo que he visto, no hay forma de expresar claramente tal dependencia en el entorno Eclipse PDE. Puedo hacer que los proyectos de complemento dependan de otros proyectos de complemento (a través de los encabezados de manifiesto Import-Package o Require-Bundle ), pero no de los proyectos Java simples.
Parece que puedo hacer que project declare una dependencia de un jar de otro proyecto en un espacio de trabajo, pero estos archivos jar no se recogen ni exportan ni ejecutan la configuración (aunque, la edición de código java ve las bibliotecas muy bien).
Los "proyectos Java" se utilizan para crear servicios que se implementarán en un contenedor J2EE (JBoss 4.2.2 por el momento) y producen en algunos casos varios jar''s: uno para implementar en el JBoss ear y otro para el uso del código del cliente ( Aplicación RCP).
La forma en que hemos "resuelto" este problema por el momento es que tenemos 2 configuraciones de lanzador de herramientas externas más, una para construir todos los jar y otra para copiar estos jar a los proyectos de plug-in. Esto funciona (más o menos), pero los objetivos de "compilación completa" y "copia de compilación" incurren en un gran paso de compilación, eludiendo toda la función de compilación incremental de eclipse y copiando los jars en lugar de solo hacer referencia a los proyectos. Desacoplando la información de dependencia y solicitando una renovación bastante masiva del espacio de trabajo que devora el tiempo de desarrollo como si fuera un caramelo.
Lo que me gustaría tener es una configuración de espacio de trabajo mucho más "natural" que gestione las dependencias entre proyectos y solicite reconstrucciones incrementales solo cuando sean necesarias, pueda usar el código de cliente de bibliotecas de servicios en complementos de aplicaciones RCP y pueda para iniciar la aplicación RCP con todas las clases necesarias donde se necesiten.
Entonces, ¿puedo comer mi pastel y comerlo también?)
NOTA
Para ser claros, no se trata tanto de gestión de dependencias y gestión de módulos en este momento como de configuración de Eclipse PDE.
Conozco bien productos como [Maven], [Ivy] y [Buckminster] y resuelven un problema bastante diferente (una vez que he resuelto el problema de configuración del espacio de trabajo, estos productos pueden ser útiles para materializar el espacio de trabajo y construir el producto)
Con un conjunto complejo de dependencias de compilación, he encontrado que Maven2 y Hudson (para CI) son una combinación bastante agradable. Me tomó un tiempo configurar la infraestructura y ponerme a la cabeza de la configuración, pero después de eso, funcionó.
Por supuesto, usted depende entonces del soporte de Maven2 (o Hudson) para su mecanismo de compilación. No estoy seguro de si las construcciones de Eclipse Headless son compatibles. Pero si la única razón por la que está usando Eclipse sin cabeza es permitir que las dependencias se expresen en un solo lugar, hágase un favor y cambie.
Los proyectos de Eclipse dependen uno del otro en virtud de la casilla de verificación en las propiedades del proyecto (¿proyectos dependientes?), Que es la forma en que Eclipse decide qué construir. Puede configurarlo usted mismo, pero generalmente se establece cuando cambia la ruta de compilación de Java. Almacena los datos en el archivo .Project IIRC, por lo que una vez que haya pasado por la GUI y haya visto los cambios, podrá ser más flexible en la forma de aplicar los demás.
Sin embargo, parece que quieres mezclar y combinar Tarros y Paquetes. La manera más fácil de hacerlo es simplemente tratar todos los proyectos como proyectos de Java. En el proyecto PDE, puede entrar y modificar la ruta de compilación de Java; se quejará y dirá que no es la manera correcta de hacerlo, pero le permitirá tener un proyecto PDE que dependa de un proyecto Java sin todo ese mullido TAREA. Una vez dicho esto, no me sorprendería si hubiera problemas de tiempo de ejecución con este enfoque: es probable que el tiempo de ejecución PDE no lo vea de esa manera.
El otro enfoque es hacer que sus archivos JAR sean paquetes PDE / OSGi. Después de todo, un paquete OSGi no es más que un JAR con un poco de cruxt adicional en el Manifiesto, y le permitirá desarrollar y ensamblar sus proyectos de manera trivial utilizando la administración automática de dependencias. Probablemente sea el más fácil, incluso si realmente no necesita que el manifiesto esté presente en sus paquetes. Pero hacer esto significará que su aplicación PDE se puede enviar con un enfoque más modular en lugar de incrustar las bibliotecas en cada complemento según sea necesario.
Entonces, PDE puede generar paquetes OSGi, y ese es solo otro nombre para JAR + Manifiesto. Puede utilizar un JAR exactamente de la misma manera en otros entornos (por ejemplo, para su EAR u otros usos del cliente) y puede aprovechar la capa OSGi en su aplicación. Realmente no hay razón para no hacer esto dado el tipo de paquete híbrido del que está hablando.
Nuestra solución utiliza un generador de Ant para copiar los directorios de "clases" de los proyectos Java simples directamente en el directorio superior del proyecto del complemento. Nos saltamos el paso de creación de JAR para ahorrar tiempo, y funciona bastante bien. Si el proyecto de complemento depende de JAR externos que ya están construidos, los copiamos también.
Aquí es exactamente cómo configurarlo en Eclipse 3.5 (lo siento por el formato impar, pero esa es la única forma en que pude encontrar para conservar la sangría):
Create empty "classes" dir in plugin project Select plugin project, hit F5 to refresh resources Create new Ant build file in plugin project to copy dependencies (ours is shown below) Right-click plugin project, select Properties Select Builders Click "New..." (brings up Edit Configuration dialog) Select Ant Builder and click "OK" Name your builder (ours is called "PluginProject externals") Browse workspace for Buildfile (ours is ${workspace_loc:/PluginProject/copyDependencies.xml}) click Refresh tab check "Refresh resources upon completion", click "Specific resources" click "Specify Resources...", check box for the classes dir, click "Finish" Click "OK" (closes Edit Configuration dialog) Click "Up" to move "PluginProject externals" to top of builder list Click "OK" (closes Properties dialog) Open your plugin project''s MANIFEST.MF Click "Runtime" tab Click "Add..." under "Classpath", select your the "classes" dir and JARs and click "OK"
La creación manual del directorio de "clases" vacío en el proyecto del complemento es para que pueda decirle al nuevo constructor que actualice ese recurso (que aún no existe antes de que se ejecute el nuevo generador). Esto es lo que está en nuestro archivo copyDependencies.xml:
<project name="Copy dependencies" default="copyDependencies" basedir=".">
<!--
This copying is needed because it appears that Eclipse plugins can''t
depend directly on external Eclipse projects.
-->
<description>
Copies external dependency class andd JAR files into this plugin''s directory.
</description>
<target name="copyDependencies">
<copy file="../External/JDOM/jdom-1.0/build/jdom.jar" todir="." preservelastmodified="true"/>
<copy file="../External/Xalan/xalan-j_2_6_0/bin/xalan.jar" todir="." preservelastmodified="true"/>
<copy file="../External/Xalan/xalan-j_2_6_0/bin/xercesImpl.jar" todir="." preservelastmodified="true"/>
<copy file="../External/Xalan/xalan-j_2_6_0/bin/xml-apis.jar" todir="." preservelastmodified="true"/>
<copy todir="./classes/com/arm" preservelastmodified="true">
<fileset dir="../Utilities/src/com/arm" excludes="**/*.java"/>
</copy>
</target>
<target name="clean" description="Deletes local copies of external classes and JARs.">
<delete file="jdom.jar" quiet="true"/>
<delete file="xalan.jar" quiet="true"/>
<delete file="xercesImpl.jar" quiet="true"/>
<delete file="xml-apis.jar" quiet="true"/>
<delete dir="./classes/com/arm/utilities" quiet="true"/>
</target>
</project>
El único inconveniente de este método parece ser que Eclipse no es 100% perfecto para invocar el generador externo cuando necesita invocarse, por lo que ocasionalmente tiene que hacer un "Proyecto> Limpiar ..." en Eclipse para forzarlo a lo largo de .
Tienes mis simpatías. Yo también he luchado con este problema y el Wall-of-Silence de los desarrolladores de Eclipse en una pregunta tan simple y obvia: ¿cómo declarar una dependencia de un plugin a un proyecto Java normal (de modo que funcione en tiempo de ejecución)?
No creo que lo apoyen. La única manera que tengo de resolver el problema es crear carpetas dentro de mis proyectos de complemento que en realidad son enlaces a la carpeta / carpetas de los proyectos Java, y luego incluir estas carpetas en el complemento. Eso al menos funciona, pero es frágil debido a las rutas absolutas del sistema de archivos requeridas.
Estoy teniendo exactamente los mismos problemas. Tenemos un conjunto de múltiples proyectos Java normales que Maven puede construir y que (actualmente) todos compartan el mismo classpath para que funcionen correctamente. Estos proyectos se pueden usar para iniciar un servidor en un entorno que no sea OSGi. Luego, también tenemos un cliente eclipse RCP que usa estos proyectos como un solo paquete. Soy perfectamente capaz de construir este gran paquete con Maven utilizando el complemento Apache Felix Maven Bundle y todo funciona bien. Pero cada vez que cambio una clase en el proyecto normal, tengo que reconstruir todo el paquete. La creación incremental y la vinculación de recursos no funciona.
Probé la "solución" con enlaces binarios / directorios de origen de estos proyectos en la ruta de clase Manifest del one-big-bundle y parece funcionar, pero sería una verdadera pesadilla de mantenimiento porque incluso tengo que vincular algunos archivos individuales.
Irónicamente, DEBIDO al uso de OSGi en el cliente, en realidad estoy pensando en colapsar nuestra estructura agradable y modular con módulos Maven en subpaquetes de un solo proyecto de complemento. Esta es una mejor alternativa que tener un desarrollo extremadamente lento.
La otra y mejor alternativa (según los chicos OSGi) que investigaré primero es convertir todos mis módulos Maven en paquetes OSGi. Pero esto puede ser un PITA real porque dependo del escaneo classpath y combinando múltiples archivos de configuración de varios paquetes (a veces con el mismo nombre) para formar una configuración.
(Específicamente, utilizamos el marco Spring y fusionamos varios archivos persistence.xml en un contexto de persistencia. También fusionamos varios archivos XML de contexto de XML de diferentes módulos (todos proporcionan un ASPECTO diferente) que deberían formar juntos un contexto Spring para ser utilizado por Spring -DM)
quizás pueda usar "propiedades de proyecto" -> "ensamblaje de despliegue" en Eclipse y agregar otros proyectos a su proyecto principal. Los otros proyectos se ven como "jarras" que se agregan automáticamente a su archivo de despliegue (guerra, oído o lo que sea). Tal vez esto puede ser trabajos. Al menos funciona para mí. Buena suerte !!
Ariesandes.
Existe una opción de "Fuente de enlace" en Propiedades de compilación de ruta que le permite definir carpetas de origen adicionales para un proyecto. Puede seleccionar la carpeta "src" de otro proyecto de espacio de trabajo y cambiarle el nombre a "src2" o lo que desee. De esta forma, las clases se compilan e implementan en la carpeta de salida del proyecto de plug-in y pueden cargarse en tiempo de ejecución.