Consider publishing both main and no-op libs together in one multi-variant way

⚠️ Is your feature request related to a problem? Please describe

The problem is that adding this library to a project is more verbose than maybe it has to be, and can be error-prone (such as a copy-paste error with debug vs release implementation).

💡 Describe the solution you’d like

I notice you already use maven-publish (or a wrapper around it), and software components for publishing. You may not be aware that there is an all component that bundles together all variants into a single variant-aware publication. I honestly am not sure it will work in your use-case, but I think it might. The idea is to get rid of the no-op library and instead put it into a release folder in your source tree. And then the “real” lib would go into a debug folder. Publish with components.all and then users could add just one line of code to their build scripts and gradle would select the right variant at build time.

📊 Describe alternatives you’ve considered

📄 Additional context

I have a plugin that does some dependency analysis, and it falls over a bit in the presence of libraries using this pattern. I intend to work on a solution at the level of my plugin, but it got me thinking that you could improve your publishing process and make life easier on users.

🙋 Do you want to develop this feature yourself?

• Yes
• No
• Maybe

[MiSikora]

I wouldn’t want to have one bundle to rule them all based on build types and flavours. It shouldn’t be assumed how the library is applied. Maybe someone has a need for having Chucker in release builds as it is used for some sort of monitoring tool or whatever the reason is.

Also, I’m not sure if I get it correctly, but I’m afraid of issues mentioned by @koral-- as well.

If anything I would be in favour of not having no-op flavour at all. It should be up to the consumer side to decide whether they want to apply library or not. I mean, having it is not a big deal as I don’t have to apply it anyway, but just saying. 😃

[koral--]

If I understand correctly proposed approach may cause new kind of issues.

Let’s consider the following scenario:

• There is a multi-module and multi-variant app.
• Some of dependencies have only one configuration: release since there is no difference between release and debug. ** So some variants use setMatchingFallbacks("release")

With such setup those variants will pick release version of chucker which may be the opposite of the desired effect.