Especificar la ruta de clase de experto

Question

bastante nuevo para maven aquí así que vamos a explicar primero lo que yo estoy tratando de hacer:

Tenemos ciertos archivos JAR, que no será añadido al repositorio. Esto se debe a que son específicos de Oracle ADF y ya están colocados en nuestro servidor de aplicaciones. Sólo hay 1 versión que se utiliza para todas las aplicaciones en tiempo de nadie. Para compilar sin embargo, tenemos que tener estos en la ruta de clase. Hay una gran cantidad de estos recipientes, por lo que si tuviéramos que actualizar a una versión más reciente de ADF, tendríamos que entrar en cada aplicación y redefinir algunas dependencias redundantes bonitas. Así que de nuevo, mi objetivo es simplemente añadir estos archivos JAR a la ruta de clases, ya que vamos a controlar qué versión se utiliza realmente en otro lugar.

Así que, básicamente, quiero sólo tiene que añadir todos los JAR en un directorio dado red (de los cuales los desarrolladores no tienen permiso para modificar) a la ruta de clase de experto para cuando se compila. Y sin poner cualquiera de estos archivos JAR en un repositorio. Y, por supuesto, estos recipientes no deben ser empaquetados en cualquier EAR / WAR.

editar

Entre otras razones por las que no quiero añadir estos a la cesión temporal corporativa es que:

1. Estos frascos no son utilizados por cualquier otra cosa. Hay una gran cantidad de ellos, poco común y exclusivo de Oracle.
2. No sólo será una versión de un JAR concreto utilizado en el momento nadie. No habrá nunca el caso en que la aplicación A depende de 1,0 y la aplicación B depende de 1,1. Tanto Aplicación A y B dependerán ya sea 1.1 o 1.2 únicamente.
3. Estamos planeando para mantener más de 100 aplicaciones. Eso es un montón de archivos pom.xml, es decir, en cualquier momento actualizamos Oracle ADF, en su caso la dependencia no se ha especificado correctamente (a través de un error humano) tendremos que fijar cada error cada vez que editar los archivos de más de 100 pom.xml para una actualizar.

Answer 1

veo tres opciones:

1. Poner las dependencias en un repositorio (podría ser un repositorio de archivos como se describe en esta respuesta ), lo cuenten con un provided alcance.
2. Utilice el sucio truco system alcance (es decir, declarar las dependencias con un alcance del sistema y establecer la ruta de los frascos en su sistema de archivos.
3. Little variación de # 2:. Crear un frasco con una MANIFIEST.MF referencia a todos los frascos (utilizando una ruta relativa) y declarar una dependencia de este frasco casi vacío con un alcance system

La forma más limpia es la opción # 1, pero otros también funcionaría en su caso. Opción # 3 parece ser el más cercano a lo que estás buscando.

Actualización: Para aclarar la opción # 3

Digamos que usted tiene un directorio con a.jar y b.jar . Crear un c.jar con una entrada Class-Path en su lista META-INF/MANIFEST.MF otros frascos, algo como esto:

Class-Path: ./a.jar ./b.jar 

A continuación, declarar una dependencia en su POM en c (y sólo en c) con un alcance system, otros frascos se convertirán en "visible" sin tener que enumerar explícitamente en su POM (Seguro, es necesario declararlos en el manifiesto pero esto puede ser escrito con mucha facilidad).

Answer 2

A pesar de que se indique expresamente que no los quiere en el repositorio, sus razones no están justificadas. Aquí está mi sugerencia:

• instalar estos frascos en su repostory
• agregarlos como Maven dependencias, con <scope>provided</scope>. Esto significa que son proporcionados por su tiempo de ejecución (el servidor de aplicaciones) y no serán incluidos en sus artefactos (guerra / oreja)

esta pregunta similar

Es aconsejable que una organización que está utilizando ampliamente experto tiene su propio repositorio. Se puede ver Nexus . A continuación, puede instalar estos frascos en su repositorio y todos los desarrolladores van a usar, en lugar de tener solamente los frascos en cada repositorio local.

(no la opción "más feo" sería el uso de maven en absoluto, puesto puso los frascos en una ubicación relativa y añadirlos a la ruta de clase del proyecto, la presentación del archivo de propiedades de ruta de clases (dependiendo del IDE))

Answer 3

si está desarrollando ADF (10g / 11g supongo) componentes, supongo que va a utilizar como IDE JDeveloper. JDeveloper viene con una herramienta de gestión de biblioteca muy rica que le permite definir qué libaries son necesarios para compilar o cuáles deben ser envasadas para su despliegue. Yo supongo que ya sabrá cómo agregar bibliotecas de proyectos e indicar en el perfil de implementación cuáles deben ser recogidos, mientras que el envasado. Si desea mantener sus bibliotecas de experto, tal vez esto podría ser el mejor enfoque. Digamos que las bibliotecas que usted se refiere también son los "WebCenter", utilizando este enfoque, le garantiza que usted tiene las bibliotecas adecuadas como JDeveloper vendrá con las bibliotecas versión correcta.

Sin embargo, a medida que está utilizando Maven no lo recomendaría para mantener algunas bibliotecas fuera de control y repositorios de Maven. Me gustaría recomendar elegir entre experto y gestión de bibliotecas Oracle JDeveloper. En nuestro proyecto actual que estamos trabajando con JDeveloper ADF 11g (y WebCenter) y usamos Maven, simplemente se nos hace más fácil la gestión de bibliotecas. Al final del día, vamos a tener una gran cantidad de bibliotecas de terceros (Apache decir, primavera, etc.) que son útiles para ser administrado por experto y no tan muchas bibliotecas Oracle realmente necesarios para la compilación en el IDE (como se que sólo necesitan las API y no sus implementaciones). Nuestro enfoque ha sido añadir las bibliotecas de Oracle a nuestro repositorio Maven siempre que se requieren y dejar Maven para controlar toda la gestión de la dependencia.

Como otros dicen que en sus respuestas si no desea las dependencias que deben incluirse en cualquiera de sus artefactos utilizar <scope>provided</scope>. Una vez que configura su entorno de desarrollo va a ser agradecidos experto hace el trabajo y se puede (casi) olvidarse de gestión de la dependencia. Para construir el IDE JDeveloper archivos estamos usando el plugin de Maven JDev, por lo mvn jdev:jdev construiría generar nuestros archivos de proyecto y establecer dependencias en bibliotecas y entre ellos para compilar correctamente.

Actualizado:

Por supuesto, es necesario hacer referencia a las bibliotecas de ADF en sus archivos pom. En nuestro proyecto que acabamos de referirnos a las utilizadas en cada aplicación, por ejemplo ADF Tag Libraries o un servicio específico, no todo el ADF / WebCenter pila. Para ello se utiliza el alcance "proporcionado". Todavía se puede dejar que JDeveloper para administrar sus bibliotecas, pero hemos encontrado que es más fácil de tener ya sea un 100% JDeveloper bibliotecas acercan o un enfoque maven 100%. Si vas con el enfoque experto que le llevará algún tiempo para construir tu repositorio local, en un principio, pero una vez hecho esto es muy fácil de mantener, y todo el ciclo (desarrollo, construcción, prueba, el envasado y el despliegue) será más simple, que tiene una configuración más consistente. Es cierto que en un futuro tendrá que actualizar a versiones posteriores ADF, pero como ya se definirá la estructura de su repositorio debe ser algo rápido. Para las actualizaciones futuras que recomendaría a mantener la versión ADF como una propiedad en la parte superior del pom, que le permitirá cambiar rápidamente a una nueva versión.