¿Cómo expresar las dependencias del proyecto Inter en Eclipse PDE

Question

Busco la mejor práctica de manejo de dependencias del proyecto inter entre los tipos de proyectos mixtos en los que algunos de los proyectos son plug-in / OSGi proyectos de paquete Eclipse (una aplicación RCP) y otros son proyectos de Java módulos antiguos llanos justos (Web Services ). Pocos de los plug-ins de Eclipse tienen dependencias en proyectos Java.

Mi problema es que al menos por lo que yo he buscado, no hay manera de expresar limpiamente esa dependencia en el entorno Eclipse PDE. Puedo tener plug-in proyectos dependen de otros plug-in proyectos (vía Import-Package o Require-Bundle cabeceras manifiestos), pero no de los proyectos llanura Java.

Parece que soy capaz de tener proyecto de declarar una dependencia en un frasco de otro proyecto en un espacio de trabajo, pero estos archivos jar no son recogidas por ninguna configuración de exportación ni de lanzamiento (aunque, edición de código java ve las bibliotecas bien ).

Los "proyectos de Java" se utilizan para la construcción de los servicios que se implementa en un contenedor J2EE (JBoss 4.2.2 por el momento) y los productos en algunos casos múltiples de Jar - uno para el despliegue de la oreja JBoss y otro para su uso por el cliente código (una aplicación RCP).

La forma en que hemos "resuelto" el problema por ahora es que tenemos 2 herramientas más externos del lanzador configuraciones - uno para la construcción de todo el frasco de y otro para copiar estos frasco de que el plug-in proyectos. Estos trabajos (más o menos), pero el "conjunto de construcción" y "frascos de copia" objetivos incurren bastante grande paso de generación, pasando por alto la función de construcción incremental toda Eclipse y copiando los frascos en lugar de sólo hacer referencia a los proyectos que estoy disociación de la información de dependencia y solicitando una actualización masiva bastante espacio de trabajo que se come el tiempo de desarrollo como si fuera caramelo.

Lo que me gustaría tener una mayor configuración del espacio de trabajo mucho más "natural" que administraría dependencias entre proyectos y solicitud de incremento reconstruye única medida que se necesitan, ser capaz de código de uso de los clientes de las bibliotecas de servicio en una aplicación RCP plug-ins y ser capaz de iniciar la aplicación de RCP con todas las clases necesarias donde más se necesitan.

Así que puedo tener mi pastel y comérselo también;)

NOTA

Para que quede claro, esto no se trata tanto de la gestión de la dependencia y gestión de módulos en el momento ya que se trata de configuración de Eclipse PDE.

Soy muy consciente de los productos como [Maven], [Ivy] y [Buckminster] y resolver un problema bastante diferente (una vez que haya resuelto el problema de configuración del espacio de trabajo, estos productos realmente puede ser útil para materializar el espacio de trabajo y creación del producto)

Answer 1

Nunca lo hice por lo que este es un enfoque teórico. Pero me gustaría probar un sistema de gestión de la dependencia como la hiedra o maven2.

Desde hace mucho más maven2, a continuación, sólo la dependencia de gestión, lo recomiendo hiedra en este caso.

Answer 2

proyectos Eclipse dependen unos de otros, en virtud de la casilla de verificación en las propiedades del proyecto (proyectos dependientes?) Que es como Eclipse decide que construir. Puede establecer este sí mismo, sino que está establecido por lo general cuando cambie su ruta de compilación de Java. Almacena los datos en el archivo .project IIRC así que una vez que haya pasado a través de la interfaz gráfica de usuario y visto lo que cambia, puede ser más flexible en la forma de aplicar los otros.

Sin embargo, parece que usted quiere mezclar y combinar los frascos y Lotes. La forma más fácil de hacerlo es tratar a todos los proyectos como proyectos Java. En el proyecto de PDE, en realidad se puede entrar y modificar la ruta de acceso de construcción Java; que va a quejarse y decir que no es la forma correcta de hacerlo, pero permitirá que usted tenga un proyecto PDE dependerá de un proyecto Java sin toda esa esponjosa Jaring arriba. Una vez dicho esto, no me sorprendería si había problemas de tiempo de ejecución con este enfoque - el tiempo de ejecución de la PDE es probable que lo ve de esa manera

.

El otro enfoque es hacer que sus propios paquetes JAR PDE / OSGi. Después de todo, un paquete OSGi es nada más que un frasco con un poco de costra extra en el manifiesto, y que le permitirá desarrollar y ensamblar sus proyectos trivialmente usando la gestión automática de la dependencia. Eso es probablemente el más fácil de ir, incluso si no es realmente necesario el manifiesto a estar presentes en sus paquetes. Pero hacer esto significará la aplicación de la PDE puede enviarse con un enfoque más modular en lugar de incrustar las bibliotecas en cada plugin que sea necesario.

Por lo tanto, la PDE puede generar paquetes OSGi, y eso es sólo otro nombre para JAR + Manifiesto cosas. Se puede utilizar un JAR exactamente de la misma manera en otros entornos (por ejemplo, para el oído u otros usos del cliente) y usted puede tomar ventaja de la capa de OSGi en su aplicación. Realmente no hay razón para no hacerlo dado el tipo de paquete híbrido que se está hablando.

Answer 3

Nuestra solución utiliza un constructor de Ant para copiar las "clases" directorios de los proyectos planos Java directamente en el directorio superior del proyecto de plugin. Nos saltamos el JAR construcción de paso para ahorrar tiempo, y funciona bastante bien. Si el proyecto de plugin depende de JAR externos that're ya construidas, copiamos los de también.

Aquí es exactamente cómo configurarlo en Eclipse 3.5 (lo siento por el formato extraño, pero esa es la única manera que pude encontrar para preservar 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 vacío "clases" en el proyecto de plugin es para que pueda informar a su nuevo constructor para refrescar ese recurso (que aún no existe antes de que el nuevo constructor es un negocio). 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>

La única desventaja de este método parece ser que Eclipse no es 100% perfecto acerca de cómo invocar el constructor externo cuando tiene que ser invocada, por lo que de vez en cuando hay que hacer un "Proyecto> Limpiar ..." en Eclipse para forzarlo a lo largo.

Answer 4

Usted tiene mis simpatías. Yo también he luchado con este tema y la pared de silencio desde el Eclipse proyectos de desarrollo en tal una forma simple, la pregunta obvia: ¿Cómo declarar una dependencia de un plugin para un proyecto Java normal (de tal manera que funciona en tiempo de ejecución)

No creo que lo apoyan. La única manera Ive consiguió solucionar el problema es crear carpetas dentro de mis proyectos de plugin que en realidad son enlaces a la papelera / carpetas de los proyectos de Java, y luego se incluyen estas carpetas en el plugin. Que al menos funciona, pero su frágil debido a los caminos del sistema de archivos absoluta requerida.

Answer 5

tal vez usted puede utilizar las propiedades del proyecto "" -> "El despliegue de montaje" en Eclipse, y añadir otros proyectos para su proyecto principal. Los otros proyectos están viendo como los "tarros" que se agregan automáticamente a su archivo de despliegue (la guerra, el oído o lo que sea). Tal vez esto puede ser obras. Al menos a mí me funciona. Buena suerte !!

Ariesandes.

Answer 6

Hay una opción de "fuente de Enlace" en las propiedades de trayectoria de la estructura que le permite definir las carpetas de origen adicionales para un proyecto. Puede seleccionada la carpeta "src" de otro proyecto de espacio de trabajo y cambiar su nombre a "Src2" o como se quiera. De esta manera las clases se compilan y se despliegan en la carpeta de salida de plug-in de proyectos y se pueden cargar en tiempo de ejecución.

Answer 7

Con un complejo conjunto de dependencias de construcción, he encontrado Maven2 y Hudson (por IC) que es una combinación bastante agradable. Se tomó un tiempo para establecer la infraestructura y conseguir mi cabeza alrededor de configuración, pero después de eso, sólo funcionó.

Por supuesto, usted es entonces dependiente de Maven2 (o Hudson) apoyo a su mecanismo de acumulación. No estoy seguro de lo bien Eclipse sin cabeza compilaciones son compatibles. Pero si la única razón por la que estás usando Eclipse sin cabeza es permitir que las dependencias que se expresan en un solo lugar, hágase un favor y el interruptor.

Answer 8

Estoy teniendo exactamente los mismos problemas. Tenemos un conjunto de múltiples proyectos de Java normales que se pueden construir por Maven y debe (en la actualidad) comparten la misma ruta de clase para trabajar correctamente. Estos proyectos pueden ser utilizados para iniciar un servidor en un entorno no-OSGi. Luego también tenemos un cliente Eclipse RCP que utiliza estos proyectos como un solo paquete. Soy perfectamente capaz de construir este un gran paquete con Maven usando el Apache Maven Felix Bundle Plugin y todo funciona bien. Pero cada vez que cambio de una clase en el proyecto normal, tengo que reconstruir todo el paquete. construcción incremental y la vinculación de recursos no funciona.

Probé la "solución" con la vinculación de directorios binarios / fuente a partir de estos proyectos en la ruta de clase Manifiesto de la de un gran paquete y parece que funciona pero sería una verdadera pesadilla para el mantenimiento, porque incluso tengo para enlazar un individuo archivos.

Así que, irónicamente, debido a la utilización de OSGi en el cliente en realidad estoy pensando en el colapso de nuestra agradable y estructura modular con módulos Maven en subpaquetes de un solo proyecto de plugin. Esta es una alternativa mejor que tener el desarrollo extremadamente lento.

La otra alternativa y mejor (según los tipos de OSGi) que voy a investigar primero es hacer que todas mis módulos Maven en paquetes OSGi. Pero esto puede ser un verdadero PITA porque dependo de escaneo ruta de clases y la combinación de múltiples archivos de configuración desde varios paquetes (a veces con el mismo nombre) para formar una configuración.

(Específicamente utilizamos el marco de Primavera y fusionar varios archivos persistence.xml en un contexto de persistencia. También unir varios archivos XML de contexto primavera de diferentes módulos (todos ofreciendo un aspecto diferente) que juntos forman un contexto debe ser la primavera utilizado por la primavera-DM.)