Separación de paquete frente a proyecto en java

Question

En primer lugar, voy a (regresar) a Java desde C#, así que me disculpo si mi terminología o filosofía no se alinean del todo.

Aquí está el fondo: tenemos una creciente colección de herramientas internas de soporte escritas para la web. Usan HTML5/AJAX/otras palabras de moda para el frontend y Java para el back-end. Estas herramientas utilizan un marco interno liviano para que puedan compartir una interfaz administrativa para seguridad y otra configuración. Cada herramienta ha sido escrita por un autor diferente y espero que esa tendencia continúe, por lo que me gustaría facilitar que los futuros autores permanezcan "estandarizados" en las bibliotecas de terceros que ya hemos decidido utilizar para las cosas como DI, las pruebas unitarias, ORM, etc.

Nuestra denominación paquete actualmente tiene el siguiente aspecto:

• com.ourcompany.tools.framework
• com.ourcompany.tools.apps.app1name
• com.ourcompany.tools.apps.app2name

... y así sucesivamente.

Así que aquí está mi pregunta: ¿debería tratar cada una de estas aplicaciones (y el marco) como un proyecto separado para propósitos de configuración de Maven, Eclipse, etc.?

Podríamos tener muchas aplicaciones que aparecen aquí a lo largo del tiempo, por lo que parece que la separación mantendría las dependencias más limpias y permitiría a alguien recurrir a una sola herramienta más fácilmente. Por otro lado, (1) tal vez "dividir" porciones más profundas de una estructura de paquete sobre múltiples proyectos es un olor a código y (2) mantenerlos combinados haría que los escritores de herramientas se inclinaran más a utilizar bibliotecas de terceros ya instaladas para el otro herramientas.

FWIW, mi instinto inicial es separarlos.

¿Qué dicen ustedes, gurús de Java?

Answer 1

Guardo mis proyectos separados, pero uso un pom padre para incluir todas las dependencias y otras propiedades comunes. Las herramientas/proyectos individuales tienen un nombre y una referencia al proyecto principal y cualquier dependencia específica del proyecto, si corresponde. Esto funciona para ayudar a mantener las bibliotecas y dependencias comunes, ya que las comunes ya están configuradas, pero me permite centrarme en la parte específica de la base de código con la que necesito trabajar.

Answer 2

Los separaría por completo. Para los propósitos de Maven, asegúrese de que cada aplicación/proyecto tenga las dependencias apropiadas para el marco/aplicaciones para que no tenga que construir todo cuando solo quiera construir una sola aplicación.

Answer 3

Si hay una sección de un proyecto que probablemente se utilizará en más de un proyecto, tiene sentido sacarlo. También lo hará un poco más limpio si necesita actualizar el código en uno de los proyectos comúnmente utilizados.

Answer 4

Definitivamente separaría este tipo de cosas en proyectos separados.

Debe usar Maven para manejar las dependencias/proceso de compilación de forma automática (tanto para sus propias bibliotecas compartidas internas como para las dependencias de terceros). No habrá ningún problema al hacer que múltiples aplicaciones hagan referencia a las mismas bibliotecas compartidas, incluso puede mantener múltiples versiones si es necesario.

par de bonos de este enfoque:

• Esto obliga a pensar cuidadosamente acerca de su diseño API para los proyectos compartidos que será algo bueno en el largo plazo.
• Es probable que también le dará sobre la granularidad adecuado para el control de código fuente - es decir, los desarrolladores pueden revisar y trabajar en aplicaciones o módulos del backend específico individual

Answer 5

Si se mantiene juntos tendrá menos obstáculos en desarrollo , construyendo y desplegando sus herramientas.

Tuvimos la situación opuesta, con muchos proyectos separados. Después de fusionarlos en un árbol de proyecto, somos mucho más productivos y esto es más importante para nosotros que cualquier convención que sea tendencia.