2010-04-23 6 views
6

ejemplo:
Para el registro, mi código usa log4j. pero otros tarros de los que depende mi código usan, en su lugar, slf4j. Por lo tanto, ambos jarrones deben estar en la ruta de compilación. Desafortunadamente, es posible que mi código use directamente (dependa de) slf4j ahora, ya sea por ayuda contextual o por algún otro cambio de desarrollador. Me gustaría que cualquier uso de slf4j aparezca como un error, pero mi aplicación (y las pruebas) aún lo necesitarán en la ruta de clase cuando se ejecute.eclipse, un classpath para compilar, otro para ejecutar

explicación:
Me gustaría saber si esto es posible en eclipse. Este escenario sucede a menudo para mí. Tendré un proyecto grande, que usa muchas bibliotecas de terceros. Y, por supuesto, esos frascos de terceros también tienen sus propias dependencias. Así que tengo que incluir todas las dependencias en el classpath ("ruta de compilación" en eclipse) para la aplicación y sus pruebas para compilar y ejecutar (desde dentro de eclipse).

Pero no quiero mi código para usar todos esos contenedores, solo las pocas dependencias directas que he decidido. Entonces, si mi código usa accidentalmente una dependencia de una dependencia, quiero que aparezca como un error de compilación. Idealmente, como clase no encontrada, pero cualquier error sería suficiente.

Sé que puedo configurar manualmente el classpath cuando se ejecuta fuera de eclipse, e incluso dentro de eclipse puedo modificar el classpath para una clase específica que estoy ejecutando (en las configuraciones de ejecución), pero eso no es manejable si ejecuta mucho de casos de prueba individuales, o tienen muchas clases principales().

Respuesta

0

Parece que sería mejor administrarlo con maven, integrado en eclipse con m2eclipse.

De esta manera, solo puede ejecutar parte del ciclo de vida de construcción de maven, y puede administrar un conjunto separado de dependencias por cada paso de compilación.

0

En mi experiencia que ayuda a ser más resrictive, hice el equipo de llenado de formularios (papel) por qué se necesita y lo que este frasco de licencia ...

y ellos más bien que escribir en unas pocas líneas de código en lugar de arrastrar a lo largo de 20 jarras para abrir un archivo usando solo una línea de código u otra 'característica' elegante.

El uso de maven podría ayudar por un tiempo, pero cuando veas por primera vez jarras con nombres como nightly-build o snapshot, sabrás que estás en el infierno.

conclusión: Elija dependencias así

2

Parece que su proyecto tiene suficientes relaciones de dependencia que podría considerar estructurarlo con paquetes OSGi (complementos). Cada paquete tiene su propio cargador de clases y llega a especificar qué haces (y opcionalmente rangos de qué versión, etc.) de los que depende, de que paquetes exporta, ya sea re-exportaciones cosas de sus dependencias, etc.

Eclipse en sí es estructurado a partir de complementos y fragmentos de Eclipse, que son solo paquetes OSGi con un pequeño bit opcional de cableado Eclipse adicional (plugin.xml, que se utiliza para declarar los "puntos de extensión" y "extensiones" de Eclipse) conectados. Por lo tanto, Eclipse tiene herramientas bastante buenas para crear y gestionar paquetes integrados (a través del entorno de desarrollo de plugins). Mucho de lo que descubres puede llevarte a combinar el "paquete OSGi" con "el complemento que amplía el IDE de Eclipse", pero los dos conceptos son bastante separables.

Las herramientas Eclipse distinguen con bastante claridad (y algunas veces molestamente, pero en la forma de "medicina útil") entre los paquetes en su entorno de compilación frente a los paquetes que incluye una configuración de ejecución particular.

Después de unos años de vivir en OSGi land, el "classpath" predeterminado de Java se siente raro e incluso algo roto para mí, en gran parte porque (como has experimentado) arroja todos los JAR en una arena gigante y esperanzas ellos pueden resolver las cosas. El entorno OSGi me da mucho más control sobre las relaciones de dependencia, y como un "efecto secundario" también exige naturalmente una aclaración de esas relaciones. Entre estas declaraciones claras y la aplicación de las herramientas, la estructura del proyecto es más obvia para todos en el equipo.

si mi código utiliza accidentalmente una dependencia de una dependencia, quiero que se muestre como un error de compilación. Idealmente, como clase no encontrada, pero cualquier error sería suficiente.

Ponga su código en un complemento, sus dependencias directas en otros complementos, sus dependencias en otros complementos, etc. y declare las dependencias de cada plugin. Eclipse hará inmediatamente lo que quieras. No se le ofrecerán contenidos de dependencias de dependencias en autocompletos; obtendrás garabatos rojos y errores de compilación; etc.

+0

otra buena respuesta, lástima que solo puedo elegir una. – DragonFax

0

¿Sería útil usar el frasco slf4j-over-log4j? Eso permite usar slf4j con el registro real yendo a log4j.

Cuestiones relacionadas