Maven compatibility changes (intransitive warnings and "configuration not public")#2345
Maven compatibility changes (intransitive warnings and "configuration not public")#2345
Conversation
withInterProjectFirst when set to true will prioritize inter-project resolver over all other resolver and Ivy cache. This aimed to workaround the fact that on Maven Test configuration is considered private, and thus project dependency with `test->test` configuration may not under some condition. The condition is when someone resolves `x:y:1.0` and you have a subproject named and versioned exactly that, and some other subproject tries to depend on it. This happens when the project does not change the version number on the Github.
There was a problem hiding this comment.
Shall we try and make a reference to the fact that this is dependant on publishMavenStyle (as it is in the notes)?
I'm just not sure if "but Maven repositories" is sufficient to understand that this is because publishMavenStyle is set to true.
|
A wombo combo double bugfix PR, nice! Can I exploit this PR to ask, how come we have some settings that aren't that - settings, but rather 1 minor logging comment, other than that LGTM! |
That's a good question. I first saw these flags for name hashing https://github.com/sbt/sbt/blob/0.13/compile/inc/src/main/scala/sbt/inc/IncOptions.scala#L138-L141 |
Maven compatibility changes (intransitive warnings and "configuration not public")
|
Kudos: tested on an sbt build of spark, which exhibits this problem through sbt-pomreader. This fixes it ! :) |
intransitive warning
Made a minor improvement on @jsuereth's #2127, and split the handling to its own object called
CompatibilityWarning. This is now invoked duringupdaterather waiting tillmakePom, which might be too late."configuration not public": Adds
withInterProjectFirst()Fixes #1827.
withInterProjectFirst()option when set totruewill prioritizeinter-projectresolver over all other resolvers and the Ivy cache. This is aimed to workaround the fact that on Maven,Testconfiguration is considered private, and thus project dependency withtest->testconfiguration may not under some condition: The condition is when someone resolvesx:y:1.0and you have a subproject named and versioned exactly that, and some other subproject tries to depend on it. (182374c)This does happen when a project publishes to Maven and then someone grabs the code from Github, which is the case for
twitter-util. I've run into this myself during sbt modularization, and apparently it happens with spark development too./review @dwijnand, @Duhemm, @jsuereth