Si tiene el Proyecto A y necesita todas las dependencias del Proyecto B, ¿declara al Proyecto B padre del Proyecto A, usando herencia o una dependencia del proyecto A? Parecen tener el mismo efecto.Declarar como dependencia o como padre
Los dos enfoques son diferentes, uno es la herencia y el otro es una dependencia simple.
por la dependencia que sólo tendrá las dependencias transitivas binarios del proyecto B.
Al utilizar como un proyecto principal que va a heredar las configuraciones como plugins, la construcción de modelo, repositorios, la gestión de la dependencia, dependencias y etc., depende del caso.
Mi regla de oro es para la configuración de scm, la configuración del proyecto y las normas de desarrollo o de la compañía. Utilizo un proyecto principal (herencia).
Yo diría que si el proyecto B es destinados a actuar como un "padre universal" o algo por el estilo - es decir, un punto de partida para muchos proyectos con dependencias idénticos (o con el mismo punto de partida para sus dependencias) luego avance y haga que B sea parent.
De lo contrario, si es en realidad más de una "cosa útil tener" - por ejemplo, que tiene métodos de utilidad/tipo de núcleo que muchos de los proyectos encontrarán útil, pero no dependen para su existencia, entonces lógicamente es una dependencia.
Incluso podría considerar dividir el Proyecto B en dos a lo largo de esas líneas. Eso es lo que he hecho en el pasado:
mygroup-parent es un proyecto que consiste únicamente en un fichero POM con dependencias que quiero cada proyecto a conseguir - la aplicación de un enfoque estándar. Por ejemplo, tengo TestNG y Mockito allí.
mygroup-core es un proyecto completo de Java que tiene cosas útiles que se acostumbran mucho, pero no son una necesidad. Tengo métodos de ayuda para cosas específicas de mi sitio y dependencias como Apache HttpClient y Google Guava.