Revisando la jerarquía de dependencias de Spring Cloud
![Imagen](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEis46hK6tUcWkVVT5snGVjG0gdMbfMgU8szssajK0UMKEQw4O6czijLgD6YT8JNSQ0o-1IWEAk-rLfZEdzZGwvi-FYaX0xwZmTc21nFJbaoPg58oJM2sV3_6UzFqCwhRWsVprYB5FDlc0BX/s640/Jerarqu%25C3%25ADa+Spring+Cloud+%2528Camden.SR5%2529.png)
Estos días he estado revisando la organización de los proyectos de Spring Cloud : cómo gestionan las dependencias, cuál es la jerarquía y las relaciones entre los proyectos a la hora de hacer las builds con Maven, etc. Spring Cloud está formado por un buen número de subproyectos (Spring Cloud Config, Spring Cloud Netflix, Spring Cloud Sleuth, ...) y se hace necesario, por un lado, controlar las dependencias transitivas de los proyectos (para alinear versiones y evitar conflictos que podrían darse si cada uno se compila con diferentes versiones de otras librerías), y por otro, ofrecer un BOM (Bill of Materials) o parent a los consumidores para que puedan utilizar los artefactos de Spring Cloud con facilidad, minimizando posibles conflictos a la hora de gestionar las versiones. A pesar de haberle echado un ojo hace ya tiempo en el trabajo me había quedado con la espina de revisar en detalle todas las dependencias y construir un mapa con las versiones exactas de los proyectos en un mome