¿Cómo organiza los recursos no fuente disponibles en el classpath en su proyecto java?

Question

En un proyecto de software escrito en Java a menudo tiene recursos, que son parte del proyecto y deben incluirse en el classpath. Por ejemplo, algunas plantillas o imágenes, que deberían ser accesibles a través de classpath (getResource). Estos archivos deben incluirse en un archivo JAR producido.

Está claro que estos recursos deben agregarse al sistema de control de revisión. ¿Pero en qué directorio pones estos archivos? ¿Paralelo a los archivos de origen java o en otro directorio que también reproduce la estructura de paquete necesaria?

Answer 1

Prefiero su última solución: un directorio separado que imita el código fuente & # 8217; estructura del paquete. De esta forma, no ganarán & # 8217; t bloquearán su código fuente pero estarán justo al lado de los archivos de clase compilados en el archivo JAR empaquetado.

Answer 2

Maven los coloca en src / main / resources / (el código Java iría a src / main / Java/). La razón principal es que Maven puede compilar código en varios idiomas y tiene sentido mantenerlos separados para que una compilación no se confunda con los archivos de otro.

En el caso de los recursos, Maven reemplazará las variables en ellos antes de que se agreguen a un Jar, por lo que son " compilados " fuentes también.

Answer 3

Personalmente, preferiría tenerlos junto con el código fuente si están fuertemente relacionados con partes específicas del código, y si no hay demasiados.

Pero si tiene sentido que esos archivos tengan su propia estructura organizativa, o si hay cientos de archivos que dificultarían encontrar el código fuente entre ellos, los mantendría separados.

Answer 4

Depende de tus preferencias. Mezclarlos con los archivos de código fuente hace que las refactorizaciones, como el cambio de nombre de los paquetes, sean más fáciles (ya que los recursos se mueven junto con las fuentes), pero con más de un puñado de íconos, imágenes y archivos de localización, obtienes un montón de archivos muy fácilmente.

Con las herramientas de hoy tampoco importa. Ya sea que use Eclipse, Netbeans u otra herramienta, todas le permiten tener paquetes binarios con un diseño diferente al del código fuente. Así que al final puedes hacerlo como quieras.

Personalmente trato de evitar mezclar la fuente con los recursos, porque normalmente cambio los recursos muy raramente, pero el código fuente con mucha frecuencia.

Answer 5

Normalmente voy así:

project/src
project/resources
project/classes
project/lib
project/dist

Tanto src como resources tienen la estructura del paquete y el archivo de compilación toma clases y recursos como entrada para el frasco que se coloca en dist .

Cuando se ejecuta internamente, el classpath es algo así como: lib;classes;resources;

Si la aplicación tiene una instalación, el instalador crea y coloca el directorio de recursos intacto en la instalación.

Answer 6

Puede poner estas cosas en el classpath si su herramienta de compilación no se confunde. Eclipse no intentará compilar sus archivos JPEG ni tampoco Ant, por lo que no hay mucho de qué preocuparse. Lo bueno es que si tiene muchas cosas relacionadas, puede mantenerlas juntas, organizadas por funcionalidad en lugar de por tipo de archivo.

Hacemos esto donde trabajo; Tenemos mensajes de correo electrónico que requieren un poco de código y un puñado de recursos estáticos. Todas estas cosas se mantienen juntas en una carpeta en la ruta de origen de Java; podemos agregar y eliminar un correo electrónico del sistema fácilmente, sin olvidar cosas o cometer errores como rutas de recursos / src que no coinciden o archivos huérfanos en un árbol que no están presentes en otro árbol.

Answer 7

Como ya se dijo, depende de usted y puede variar según el proyecto. Por ejemplo, con Wicket , es bastante habitual y práctico mantener .html archivos justo al lado de las clases. Además, a menudo mantengo alguna configuración junto con el código fuente: META-INF, WEB-INF, registro.

Para que Maven tome recursos del árbol de origen, use esto:

<build>
   <resources>
     <resource>
         <directory>src/main/resources</directory>
     </resource>
     <!-- Web - Wicket -->
     <resource>
         <filtering>false</filtering>
         <directory>src/main/java</directory>
         <includes><include>**</include></includes>
         <excludes><exclude>**/*.java</exclude></excludes>
     </resource>
  </resources>

  <testResources>
     <testResource>
         <directory>src/test/resources</directory>
     </testResource>
     <!-- Web - Wicket -->
     <testResource>
         <filtering>false</filtering>
         <directory>src/main/java</directory>
         <includes><include>**</include></includes>
         <excludes><exclude>**/*.java</exclude></excludes>
     </testResource>
  </testResources>

La razón principal para mantener los recursos separados es (en mi humilde opinión) la separación de los roles de trabajo. P.ej. si tiene un proyecto con equipos de traducción, mantendría los recursos con cadenas separadas del código y con diferentes privilegios SCM.