Allow customizing defaultConfMapping in InlineConfiguration

[dansanduleac]

The defaultConfMapping in ivy is currently hard-coded to *->default(compile). This works well for most purposes, but I have a use case where it falls short.

Say I want to have a flag that, when enabled, requires users to list all their compile dependencies explicitly. Everything they depend on + their transitive dependencies will end up in the runtime scope, but compile will only contain packages explicitly listed as dependencies.
This is what some call the include-what-you-use principle, and it's useful to prevent you from using code from a transitive dependency B, in case your dependency A that depended on B stops depending on B later on, and subsequently causes your code to not compile anymore, even though you haven't made any changes to it.

Let's say I build all my packages to export an only-me configuration, that contains only the artifacts published, but no dependencies. Now, when I activate this flag, it would be a pain to have to change all the dependencies in that project from

• no dependency mapping at all, or
• compile

to compile->only-me(default).

But if we can modify the defaultConfMapping, we'd just set that to *->only-me(default), and this would do what you want without having to parse the configuration mapping of each dependency and mangle it programmatically.

[dansanduleac]

The test failure is unrelated, other 3 test suites completed fine:

:::: WARNINGS
        [FAILED     ] org.scala-lang#scala-compiler;2.10.5!scala-compiler.jar: Downloaded file size doesn't match expected Content Length for https://jcenter.bintray.com/org/scala-lang/scala-compiler/2.10.5/scala-compiler-2.10.5.jar. Please retry. (17889ms)

[dansanduleac]

Could someone look at this please? :)

[eed3si9n]

I think this feature would make the documentation of librarymanagement module more difficult. Isn't this something that could be implemented at the plugin layer? I might be open to more general ModuleID => ModuleID transformer, but this feels too specific to Ivy.

[jvican]

Were you ever able to use the include what you use principle without this fix @dansanduleac ?

[dwijnand]

Where do we stand on this PR?

@eed3si9n if this can't be implemented with a plugin, do you still feel like you'd rather this were implemented with a ModuleID => Module function?

@dansanduleac are you still interested in landing this PR? Looks like there are conflicts with the target branch, are those hard to resolve? What do you think about Eugene's plugin idea? Or implementing this with a transforming function?