This message was deleted.

maybe https://github.com/jraska/modules-graph-assert?

Hmm right this does what I need. Albeit much more than I need perhaps. I could look into the implementation though and extract the minimum code needed to just do that maybe. Thanks for the link!

Maybe this?

configurations.all {
    resolutionStrategy {
        eachDependency {
            require(requested.group != "showcase" || !requested.name.startsWith("feature-")) {
                "Do not depend on a feature module you moron"
            }
        }
    }
}

Aha, thanks for this! So this is what I’d want to include in all of my “feature modules”, so that if they themselves are trying to depend on another feature module this will just fail. Because I do not see a way to set this up in a central spot, since inside the block I only see the requested dependency, not necessarily who is it that is requesting it. Since it’s fine for my

:app

module to depend on all the feature modules, but that’s the only place really. And I’d need to make sure to properly have each of my feature modules have this code block. I suppose if I make a convention plugin which adds this and make all of my feature modules use it, then I’ll be good. Does this sound reasonable?

Yes, convention plugin is exactly the proper way to go

Thanks a lot Björn! This looks super nice actually, it crashes when trying to build as I wanted it to, and it’s very straight-forward. As long as we remember to use the convention plugin on all of our feature modules of course 😄 Simple PR. Side question about gradle in general, I’ve definitely seen people in the past discuss not using

.all {

but to use

.configureEach {

, is it that it does not matter in this context, therefore we use

all

or is it some other reason that is important in particular here?

.all

action causes all elements to be immediately realized when they are added and configured

.configureEach

action only runs as soon as the element is realized due to some other reason and only if it actually is realized For built-in things this mainly makes sense on the

tasks

container as you do not want all tasks to be configured as this wastes much time. For the

configurations

container it - at least currently - is not really relevant which of both you use as it is not treated lazily anyway so either way all get realized and configured.

Thank you again 😊 That makes sense!