On Tue, Sep 13, 2016 at 2:50 PM, jieryn <[email protected]> wrote: > I reported this for Arquillian, earlier... > https://mail-archives.apache.org/mod_mbox/maven-dev/201608.mbox/% > 3CCAArU9ia0C7bdvHEMTX3BU%3DChnrb-_chtw8N3xokvKO2_ > Rnzf1A%40mail.gmail.com%3E > > Arquillian also follows that style of multiple type=bom concentrators > which are recommended practice. Even though Maven is the one reporting > this issue, and I was originally kind of irritated about it, I have > changed stance.. > > I think Spring and Arquillian are actually doing the wrong thing here. > Users of these packages ought to just specify the versions they want > to include in their dependencyManagement section, and allow the normal > Maven dependency resolution to pull in the other artifacts. I think > the type=bom is generally wrong and lazy, without much benefit, and as > we can now see, it can actually lead to unpredictible builds/bad when > multiple bom concentrators reference each other. >
Actually, I thought we were doing the right thing. I've done my homework and realized that some of these boms do indeed import things they shouldn't so I see the warning as a good thing and something that's forcing us to fix this. With that clarified, I think we should improve the error message somehow. If we could state which pom imports conflicting versions it would be quite better. Also I still have no idea what the following means: "rearrange the causing imports in the inheritance hierarchy to apply standard override logic based on artifact coordinates." Thanks! S. > > I don't think I've seen a more clear piece of evidence for Maven > pom.xml technical debt. :-) > > On Tue, Sep 13, 2016 at 4:30 AM, Stephane Nicoll > <[email protected]> wrote: > > Hi, > > > > This command creates a vanilla project using Spring Cloud that has a > > hierarchy of BOMs > > > > curl https://start.spring.io/starter.zip -d > > dependencies=cloud-config-client -o demo.zip > > > > extract and run and you'll get plenty of warnings[1] > > > > I am trying to make sense of this message: > > > > To resolve this conflict, either declare the dependency directly in the > > dependency management of model > > 'org.springframework.cloud:spring-cloud-consul-dependencies:pom:1.0.2. > RELEASE' > > to override what gets imported or, as of Maven 3.4, rearrange the causing > > imports in the inheritance hierarchy to apply standard override logic > based > > on artifact coordinates. Without resolving this conflict, your build > relies > > on indeterministic behaviour > > > > Spring Cloud is formed of various projects that have different release > > cycles. They are aggregated in a "release train BOM" that imports other > > boms to provide a global dependency management to the user. It looks like > > something is wrong in that setup but I fail to see why. > > > > Can someone help me with this? > > > > Thanks! > > S. > > > > [1] https://gist.github.com/snicoll/cef801932814a15f35180cc8c173f2a8 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
