esquema de repositorio para grandes Maven proyecta

Question

Tengo una aplicación de gran tamaño (~ 50 módulos) utilizando una estructura similar a la siguiente:

• Aplicación
  • Módulos de comunicación
    • color módulo de comunicación
    • módulo de comunicación SSN
    • etc. módulo de comunicación
    módulo
    • Los módulos de servicio
  • Router
    • servicio votación módulo
      • submódulo interfaz web para la votación
      • Voto colector submódulo para la votación
      • etc., para votar
    • módulo de servicio del concurso
    • etc. módulo de

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

Uno está utilizando 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

Tenemos una aplicación bastante amplia (más de 160 paquetes OSGi donde cada paquete es un módulo Maven) y la lección que aprendimos, y 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 deberá 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 a una pregunta sobre el diseño del control de versiones con algún detalle with examples at another question, puede ser relevante para su situación.

Answer 2

Creo que es mejor que acople la estructura de su directorio. 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 van a terminar 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.

Es posible que también 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 llevar demasiado lejos.