On Wed, Sep 14, 2016 at 4:51 AM, jieryn <[email protected]> wrote: > 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. >
You're basically importing a bom that contains itself dependency management for something that was already provided and with a different version. Each bom should only define the dependency management they handle and should have no opinion on other dependencies. We make that mistake in Spring Cloud as well and we're currently changing our build structure to fix that. The main reason I see this setup is when you need the bom to be both standalone (just add it and module foo will work) and to be included in a "larger scope" (add it with bar, biz and project X will work). > > 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.. > First of all, I'd like the error message to change. I still don't know to this day what it means. Second, if Maven is able to find out that two boms provide dependency management for foo with conflicting versions, It would be nice to say in which boms the inconsistency was found. > > I think this bom is useful for 1-page tutorials, but is not correct > for any serious project. > I most certainly disagree. All our stack is based on this concept and it has been very successful so far (spring framework has a bom for ages now). The problem is that new projects are more complex and more demanding and we need to find a way to make that work reliably. The fact that 3.4 has this warning is an excellent move IMO. But just change the damn error message ;-) Cheers, S. > > On Tue, Sep 13, 2016 at 10:47 AM, Stephane Nicoll > <[email protected]> wrote: > > 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] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
