Re: Company-wide pom and dependency management best practices
Thanks Tomo, > I use "mvn dependency:tree -Dverbose=true" to get the detail of tree. It shows unselected nodes. The only problem with the verbose route is that it can show wrong results on Maven 3[1][2]. I was hoping for a non-deprecated solution. [1] https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html#verbose [2] http://maven.apache.org/shared/maven-dependency-tree/ > I would also take your approach of "a dependency management pom" (BOM, bill of materials) to control transitive dependencies. Yeah, it seems that would be the best option. With regards, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell On Tue, Aug 6, 2019 at 4:40 PM Tomo Suzuki wrote: > Hi Nick, > > > I see where the different versions for a dependency are coming from? > > I use "mvn dependency:tree -Dverbose=true" to get the detail of tree. It > shows unselected nodes. > > > how can I make sure that the dependencies in the Spring Boot import take > preference over the other dependency imports > > I would also take your approach of "a dependency management pom" (BOM, bill > of materials) to control transitive dependencies. > > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management > > > On Tue, Aug 6, 2019 at 10:31 AM Nick Stolwijk > wrote: > > > Hi all, > > > > We have a company-wide pom for specific applications. In our case for > > Spring Boot applications. In this pom some of the stuff is for the build > > (plugin management, deployment management) and some for the dependencies > > (scope import for dependencyManagement). > > > > We had a buildproblem where one of the Spring Boot dependencies had the > > wrong version. It turned out the version of one of the dependencies for > > Spring Boot was overridden by another dependencyManagement import. > > > > The first question is, how can I see where the different versions for a > > dependency are coming from? I know of the dependency:tree, but that only > > shows the resolved version and not all the version options. > > > > The second question is, how can I make sure that the dependencies in the > > Spring Boot import take preference over the other dependency imports. My > > idea is to break apart the Spring Boot parent we have into a build pom > and > > a dependency management pom and require that every application import the > > dependency import pom as first dependency under dependency management. > > Would this work or am I missing something? > > > > Is there any documentation about the best practices for inheriting build > > configuration and dependency management? > > > > With regards, > > > > Nick Stolwijk > > > > ~~~ Try to leave this world a little better than you found it and, when > > your turn comes to die, you can die happy in feeling that at any rate you > > have not wasted your time but have done your best ~~~ > > > > Lord Baden-Powell > > > > > -- > Regards, > Tomo >
Re: Company-wide pom and dependency management best practices
Hi Nick, > I see where the different versions for a dependency are coming from? I use "mvn dependency:tree -Dverbose=true" to get the detail of tree. It shows unselected nodes. > how can I make sure that the dependencies in the Spring Boot import take preference over the other dependency imports I would also take your approach of "a dependency management pom" (BOM, bill of materials) to control transitive dependencies. https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management On Tue, Aug 6, 2019 at 10:31 AM Nick Stolwijk wrote: > Hi all, > > We have a company-wide pom for specific applications. In our case for > Spring Boot applications. In this pom some of the stuff is for the build > (plugin management, deployment management) and some for the dependencies > (scope import for dependencyManagement). > > We had a buildproblem where one of the Spring Boot dependencies had the > wrong version. It turned out the version of one of the dependencies for > Spring Boot was overridden by another dependencyManagement import. > > The first question is, how can I see where the different versions for a > dependency are coming from? I know of the dependency:tree, but that only > shows the resolved version and not all the version options. > > The second question is, how can I make sure that the dependencies in the > Spring Boot import take preference over the other dependency imports. My > idea is to break apart the Spring Boot parent we have into a build pom and > a dependency management pom and require that every application import the > dependency import pom as first dependency under dependency management. > Would this work or am I missing something? > > Is there any documentation about the best practices for inheriting build > configuration and dependency management? > > With regards, > > Nick Stolwijk > > ~~~ Try to leave this world a little better than you found it and, when > your turn comes to die, you can die happy in feeling that at any rate you > have not wasted your time but have done your best ~~~ > > Lord Baden-Powell > -- Regards, Tomo
Company-wide pom and dependency management best practices
Hi all, We have a company-wide pom for specific applications. In our case for Spring Boot applications. In this pom some of the stuff is for the build (plugin management, deployment management) and some for the dependencies (scope import for dependencyManagement). We had a buildproblem where one of the Spring Boot dependencies had the wrong version. It turned out the version of one of the dependencies for Spring Boot was overridden by another dependencyManagement import. The first question is, how can I see where the different versions for a dependency are coming from? I know of the dependency:tree, but that only shows the resolved version and not all the version options. The second question is, how can I make sure that the dependencies in the Spring Boot import take preference over the other dependency imports. My idea is to break apart the Spring Boot parent we have into a build pom and a dependency management pom and require that every application import the dependency import pom as first dependency under dependency management. Would this work or am I missing something? Is there any documentation about the best practices for inheriting build configuration and dependency management? With regards, Nick Stolwijk ~~~ Try to leave this world a little better than you found it and, when your turn comes to die, you can die happy in feeling that at any rate you have not wasted your time but have done your best ~~~ Lord Baden-Powell
