I'd like some opinions on module layout I have a `:fcm` module which hosts FcmService, which is a b...

# gradle

[ursus]

I'd like some opinions on module layout

I have a :fcm module which hosts FcmService, which is a basically a callback for receiving push messages. There I route the messages to my push handlers from :push
I have 2 apps in a monorepo, both of which depend on the :fcm module, ie. their push handling was identital

However, a new requirment came, for which I need to proxy push messages to a analytics library just for app A (app B fcm usage remains the same)

So I created a FcmServiceDelegate interface, and implement it differently in each app as needed. (or rather include a different delegate module)

My question is how to modularize this
would you either have root level :internal-fcm-delegate , :analytics-fcm-delegate which depends on :fcm

or, turn :fcm into a plain folder, and nest the two delegates + module for original code inside it, i.e. :fcm:internal-delegate, :fcm:analytics-delegate, fcm:service

I do like nesting in general as it scales well, however I dont like that I have to create this "base" module under the folder, where the original impl will be moved to.
Is there a way I could still have :fcm as a proper module, so it has the original FcmService class, and yet nest the :internal-delegate, analytics-delegate under it?

(Because let's say a new requirement comes which needs app C to be created and use huawei push .. and there is no need for delegates as there is only one impl, the module would be naturally called :hcm ...and that's it..but thats not super symetrical with the fcm modules now..basically I'd want :fcm module here as well, and only add the delegate module which give app uses (semantically)

something along the lines of

-- appA
implementation :fcm
implementation :fcm:internal-delegate

-- appB
implementation :fcm
implementation :fcm:analytics-delegate

-- appC
implementation :hcm

what I'm not so keen on

-- appA
implementation :fcm:service
implementation :fcm:internal-delegate

-- appB
implementation :fcm:service
implementation :fcm:analytics-delegate

-- appC
implementation :hcm

or maybe this? But it blows up root imo, i dont think its important to know theres multiple fcm impls when viewing root level

-- appA
implementation :fcm
implementation :fcm-delegate-internal

-- appB
implementation :fcm
implementation :fcm-delegate-analytics

-- appC
implementation :hcm

Thoughts? What's idiomatic?

I see retrofit is doing option 3 https://github.com/square/retrofit .. but it has just a few root folders, no a monorepo really

[Zac Sweers]

This has nothing to do with kotlin

[Sebastian Sellmair [JB]]

🤨 Common. And the 😶 reaction is not helpful or welcoming either?!
@ursus
From the channel description:

This channel is for Kotlin specific Gradle questions. For general Gradle questions, join the Gradle Community Slack → <https://gradle.com/slack-invite>

Maybe you’ll get feedback https://gradle.com/slack-invite