setfont - ¿Por qué los recursos de diseño del proyecto se mantienen separados de las fuentes de Java?

setfont java

Question

¿Por qué maven mantiene los recursos en una "carpeta de origen" separada de las fuentes de Java?

De acuerdo con mi experiencia, en Java, los archivos de recursos se tratan en su mayoría como archivos de código fuente de Java que, cuando se "compilan", solo deben copiarse como están con las clases y, finalmente, se empaquetan en el contenedor y se accede a ellos mediante los métodos del cargador de clases . getResource / getResourceAsStream , a través de classpath .

Personalmente, me parece una complejidad inútil mantener los archivos de recursos separados de las fuentes Java.

1. ¿Qué piensas?
2. ¿Hay una buena razón por la cual Maven mantiene los recursos separados de las fuentes?
3. ¿Hay alguna indicación de contador al no usar src/main/resources y src/test/resources y mantener los recursos en src/main/java y src/test/java usando maven?

Answer 1

1) ¿Qué piensas?

Pienso, es una excelente convención.

2) ¿Existe una buena razón por la cual Maven mantiene los recursos separados de las fuentes?

Sí. Sigues la convención. Todos los que tengan acceso al código de su proyecto sabrán dónde buscar el código y dónde buscar todo lo demás. Y sin duda, en caso de casos de prueba. Y qué sucederá con qué archivo se ejecutará ese complemento.

3) ¿Hay alguna indicación de contador al no usar src / main / resources y src / test / resources y mantener los recursos en src / main / java y src / test / java usando maven?

No hay una indicación contraria. Es una cuestión de convención, no hay nada malo en la forma en que organiza su propio código. De hecho, si alguna vez creaste un proyecto Wicket, verás tu HTML y tu código Java permanecerá lado a lado en el paquete Java. Pero, es solo en Wicket donde se sabe que el HTML estará junto a los archivos de Java. Pero todo lo demás va en resources carpeta de resources .

Answer 2

¿Qué piensas? Creo que los muchachos detrás de Maven deberían ejercer un poco de "separación de preocupaciones". La razón número uno para usar Maven es para el manejo de la dependencia, pero ¿por qué una licuadora me dice cómo pelar mi fruta? Para mí no tiene ningún sentido.

¿Hay una buena razón por la cual Maven mantiene los recursos separados de las fuentes? No. En un proyecto Java, la duplicación de la estructura del paquete, no una, sino tres veces, agrega trabajo innecesario al proyecto, lo que aumenta el riesgo de errores y reduce la agilidad del código.

Answer 3

Creo que la separación de código / recursos suele ser útil:

1. Los paquetes deben seguir las reglas de especificación de Java, por ejemplo, la palabra reservada, como ''int'', no está permitida. Tener paquetes ilegales en la carpeta de código fuente sería confuso.

2. Recursos tiene naturaleza de instancia, clases tiene, bueno, clases de naturaleza. Por ejemplo, puede tener clases Continent y Country en el mismo paquete, pero los recursos se organizan mejor como árbol:

   • África/
     • marruecos.txt
     • kenya.txt
   • Europa/
     • poland.txt

3. La estructura de recursos, en mi opinión, es más estable que la estructura de código. La refactorización de código ocurre a menudo, las clases se mueven de paquete a paquete para una mejor legibilidad. La obligación de mover recursos en la refactorización desalienta al desarrollador de refactor.

4. Si se requiere una carpeta de recursos separada, incluso solo para el 1% de los archivos de recursos, es razonable mover el 99% restante a esa carpeta y mantener los recursos en un solo lugar.

Sin embargo, hay casos en los que mantener los recursos y el código Java juntos es útil. Por ejemplo, las pruebas unitarias comparan la entrada y la salida; es bueno tener el archivo con la entrada y la salida en la misma carpeta que el código de prueba de la unidad.

Answer 4

Intento dar una respuesta por mi cuenta.

¿Qué piensas?

Es una complejidad adicional inútil. Así está mal: ver más abajo.

¿Hay una buena razón por la cual Maven mantiene los recursos separados de las fuentes?

La única razón por la que podría pensar es que, para alguna plataforma, esta podría ser una buena práctica. Por ejemplo, en la aplicación Mac OSX, los recursos se empaquetan por separado (en una subcarpeta diferente) que los binarios.

Creo que los recursos "externos" y los archivos de configuración, los que no se empaquetan dentro del artefacto final (archivo jar) pueden tener una buena razón para mantenerse separados de los archivos de origen. Entonces, cuando Maven empaqueta el archivo jar, sabe que esos archivos no tienen que ser incluidos, porque, por ejemplo, los queremos fuera del archivo para permitir al usuario editar esos archivos como configuración.

Pero, para las cosas que se empaquetan juntas en el contenedor (como cadenas de traducción y metadatos xml, como las asignaciones de hibernación y la configuración de Spring), no hay una buena razón para tenerlas en una ubicación separada, a menos que esperemos que nuestros usuarios las cambien. manualmente después de la implementación, como parte del proceso de configuración.

Los recursos se pueden organizar con la misma estructura de paquetes que para las clases, por lo que si tiene una clase en el paquete xyz, es posible que desee tener los recursos de los que depende en el mismo paquete, ya que representan la misma "unidad lógica": en En este caso, tenerlos en dos carpetas separadas conduce a la atención adicional requerida durante la refactorización y reorganización del paquete, ya que desea mantener las cosas sincronizadas. El ClassLoader también ofrece la posibilidad de especificar rutas relativas en el método getResourceAsStream (). Entonces, si tiene la clase xyzMyClass, puede hacer getClass (). GetResourceAsStream ("foo-bar.properties"), y los recursos se cargarán desde el mismo paquete "xyz". Así que es muy útil mantener las cosas juntas cuando tienen una dependencia estrecha.

Para los recursos externos que deben mantenerse separados también en el artefacto desplegable, es bueno mantenerlos separados, pero en este caso no veo por qué Maven trata a src / main / resources como una "carpeta de fuente java" (maven-eclipse-plugin) ya que en realidad no deben estar en la ruta de clase, sino que se debe acceder a través del sistema de archivos como archivos simples, y especialmente no desea que esos archivos se incluyan dentro del contenedor durante la construcción de Maven. Este es el caso de los íconos de la aplicación, los archivos de configuración que tal vez quiera colocar en el directorio / etc, etc.

En conclusión, hay algo erróneo en la forma en que Maven maneja los recursos, en mi opinión: si son recursos "externos", entonces no hay razón para que Maven los empaquete en el artefacto final (jar). Si no son "externos", entonces no hay razón para mantenerlos en una "carpeta de origen" separada.

¿Hay alguna indicación de contador al no usar src / main / resources y src / test / resources y mantener los recursos en src / main / java y src / test / java usando maven?

No lo sé.

La mayoría de las veces he usado el diseño predeterminado de Maven para jugar con recursos, pero en un par de veces no lo hice; tomando la precaución de declarar la ubicación del directorio de recursos no estándar en el pom (ver resources y super-pom ). Es posible alterar la estructura de directorios del proyecto de Maven especificando que en el pom:

 <build>
<directory>target</directory>
<outputDirectory>target/classes</outputDirectory>
<finalName>${artifactId}-${version}</finalName>
<testOutputDirectory>target/test-classes</testOutputDirectory>
<sourceDirectory>src/main/java</sourceDirectory>
<scriptSourceDirectory>src/main/scripts</scriptSourceDirectory>
<testSourceDirectory>src/test/java</testSourceDirectory>
<resources>
<resource>
<directory>src/main/resources</directory>
</resource>
</resources>
<testResources>
<testResource>
<directory>src/test/resources</directory>
</testResource>
</testResources>
</build>

Y no encontré problemas particulares con eso.

Me gustaría que los expertos piensen nuevamente acerca de esta convención, ya que tener una estructura de proyecto más simple ayuda al desarrollador a concentrarse más en el desarrollo y menos en encontrar cosas en varias carpetas de la estructura del proyecto mientras navega por el código de la aplicación.

Answer 5

La forma en que distingo entre los dos es que las carpetas de java predeterminadas para no permitir que se construya nada en el contenedor resultante, excepto los tipos de archivos que enumero (por ejemplo, *.class , *.html , *.properties si está utilizando Wicket) , mientras que todas las cosas en los resources se copiarán en la compilación, excepto las pocas excepciones que enumero.

Por supuesto que es solo mi convención privada, adherida por mí misma.

Answer 6

Tal vez soy el único aquí que no viene de un fondo de Java. Creo que mezclar recursos y código es muy desordenado. La separación de preocupaciones hace que su proyecto sea más limpio y más fácil de entender / mantener a medida que crece.

Intento aplicar mi propia convención de directorio a todos mis proyectos de desarrollo de software:

• bin: binarios finales utilizados por el usuario
• compilación: binarios intermedios, se pueden eliminar después de la compilación
• lib: bibliotecas externas
• src: SOLO código fuente (en este caso, archivos fuente de Java)
• recursos: todos los recursos (archivos de configuración, xmls, imágenes, html, etc.)
• docs: documentacion

Rara vez he encontrado un contexto de desarrollo cuando necesitaba cambiar esta estructura de directorios.

Usando Maven, si desea hacer una configuración rápida, use los valores predeterminados. Si desea utilizar su convención de directorio, solo necesita cambiar la configuración en el archivo pom.xml como se explicó anteriormente. Sin embargo, tenga en cuenta que algunos complementos de Maven consideran que utiliza los directorios predeterminados de Maven para los recursos binarios de fuente / salida y que tendrá que ajustar algunas configuraciones de complementos si cambia estos directorios.

Answer 7

Un punto que aún no se ha mencionado es que, obviamente, estás acostumbrado a ver proyectos con solo fuentes Java en ellos. sin embargo, si incluye otros tipos de archivos de origen, creo que la organización tiene más sentido, por ejemplo:

• src / main
  • recursos
  • Java
  • maravilloso

Cada subdirectorio tiene una clasificación específica de archivos:

• java -> cosas que se compilan como archivos java
• groovy -> cosas que se compilan como scripts groovy
• recursos -> datos no compilados utilizados para lo que sea ... (también, estos pueden filtrarse para agregar información en tiempo de compilación)

también (como ya he señalado en algunos comentarios), normalmente no hago plano el directorio de recursos. los archivos se pueden anidar en una estructura similar a un paquete o en otros subdirectorios, según corresponda (según mi criterio de organización).

Answer 8

para simplificar y facilitar el acceso, también mantenemos algunos recursos en la ruta de origen de Java. Esto lo hace conveniente para nosotros cuando desarrollamos en el nivel de GUI como plantillas de velocidad y están cerca del Código Java del Controlador. Pero tienes que decirle a maven que incluya cosas que no sean java que están en src / main / java agregando algo como esto a tu archivo pom.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<webResources>
<resource>
<directory>src/main/java</directory>
<targetPath>WEB-INF/classes</targetPath>
<includes>
<include>**/*.properties</include>
<include>**/*.xml</include>
<include>**/*.htm</include>
<include>**/*.html</include>
<include>**/*.css</include>
<include>**/*.js</include>
</includes>
</resource>
<resource>
<directory>src/main/resources</directory>
<excludes>
<exclude>**/log4j.xml</exclude>
</excludes>
</resource>
</webResources>
</configuration>
</plugin>