Maybe it is different for Spring than for Arquillian, but with Arquillian, they will (imho) correctly import a bom inside another bom, and sometimes those get out of sync. So if I import the latest arquillian:bom and the latest arquillian-transaction:bom, the arquillian-transaction:bom might reference a lower level arquillian:bom, and that will trigger this error message.
Should Maven recommend to Arquillian arquillian-transaction:bom not to include the arquillian:bom? I'm not sure they can, even if we wanted them to do it. What do you recommend here? Perhaps I am wrong to include both the arquillian:bom and arquillian-transaction:bom? It's not clear.. I think this bom is useful for 1-page tutorials, but is not correct for any serious project. On Tue, Sep 13, 2016 at 10:47 AM, Stephane Nicoll <stephane.nic...@gmail.com> wrote: > On Tue, Sep 13, 2016 at 2:50 PM, jieryn <jie...@gmail.com> 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 >> <stephane.nic...@gmail.com> 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: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
