java - tutorial - Diseño de repositorio para grandes proyectos de Maven

maven java

Question

Tengo una aplicación grande (~ 50 módulos) usando una estructura similar a la siguiente:

• Solicitud
  • Módulos de comunicación
    • Módulo de comunicación de color
    • Módulo de comunicación SSN
    • etc. módulo de comunicación
  • Módulo de enrutador
  • Módulos de servicio
    • Módulo de servicio de votación
      • Submódulo de interfaz web para votar
      • Submódulo de colector de votación para votar
      • etc. para votar
    • Módulo de servicio de prueba
    • módulo etc.

Me gustaría importar la aplicación a Maven y Subversion. Después de algunas investigaciones descubrí que existen dos enfoques prácticos para esto.

Uno está usando una estructura de árbol igual que la anterior. El inconveniente de esta estructura es que necesita una tonelada de ajustes / modificaciones para que el informe de múltiples módulos funcione bien con Maven. Otro inconveniente es que en Subversion el enfoque estándar trunk / tags / branches agrega aún más complejidad al repositorio.

El otro enfoque utiliza una estructura plana, donde solo hay un proyecto principal y todos los módulos, submódulos y partes de los submódulos son un elemento directo del proyecto principal. Este enfoque funciona bien para informar y es más fácil en Subversion, sin embargo, creo que pierdo un poco la estructura de esta manera.

¿De qué manera elegirías a largo plazo y por qué?

Answer 1

Creo que es mejor que aplana tu estructura de directorios. Quizás desee crear una convención de nomenclatura para los directorios, de modo que se organicen correctamente al ver todos los proyectos, pero, en última instancia, no creo que sea necesaria toda esa jerarquía adicional.

Suponiendo que está utilizando Eclipse como su IDE, todos los proyectos terminarán en una lista plana una vez que los importe de todos modos, por lo que realmente no obtendrá nada de los subdirectorios adicionales. Eso, además del hecho de que la configuración es mucho más simple sin toda la jerarquía adicional, hace que la elección quede bastante clara en mi mente.

También es posible que desee considerar la combinación de algunos de los módulos. No sé nada sobre su aplicación o dominio, pero parece que muchos de esos módulos a nivel de hoja podrían ser más adecuados como paquetes o conjuntos de paquetes dentro de otro módulo de nivel superior. Estoy dispuesto a mantener la coherencia de tarros, pero a veces puede tomarse demasiado.

Answer 2

Tenemos una aplicación bastante amplia (más de 160 paquetes OSGi en los que cada paquete es un módulo Maven) y la lección que aprendimos, y que seguimos aprendiendo, es que el plano es mejor. El problema con la semántica de codificación en su jerarquía es que pierde flexibilidad. Un módulo que es 100% decir "comunicación" hoy puede ser en parte "servicio" mañana y luego tendrá que mover cosas en su repositorio y eso romperá todo tipo de scripts, documentación, referencias, etc.

Así que recomendaría una estructura plana y para codificar la semántica en otro lugar (por ejemplo, un espacio de trabajo IDE o documentación).

He respondido una pregunta sobre el diseño del control de versiones con algún detalle con ejemplos en otra pregunta , puede ser relevante para su situación.