My current project is an android app built in comp...

# compose-desktop

[Colton Idle]

My current project is an android app built in compose, not CMP. they do not want to adopt compose multiplatform. no plans for it. BUT id like to run my design system library (one of the android library gradle modules in the android project) on my desktop just to view and play around with components.

what do you all think is the easiest way to do that? probably just creating a new desktop shell application, and sym linking to the library module somehow? i guess theres no easy way to take an existing android library and say "i know this can work on kmp/cmp, trust me" and have it be usable by a compose desktop app? kind of a ridiculous question but maybe someone has tried something in the past.

[Vlad Gorbunov]

You can have this design system lib/module as CMP + your main app module would define a compose desktop app.
This would give you an entry point (some main function where you would define a window) + a launch target that you can run from AS.

With this you can reference dependencies independently for android/desktop/common.

That way your desktop target would only see CMP compatible design module and you can play with it.

Thats actually first thing I did when adopting android codebase to run on desktop.

[ursus]

afaik the desinglkb would have to be cmp, android can depend on cmp

[Pablichjenkov]

Basically above. Extract your library code out to a CMP project that supports jvm. Although you could do jvm and Android, in case you have some Android specifics.
Then consume the Library artifact produced by this CMP project from both of your clients. Your client App and your Demo Desktop App

[Colton Idle]

gotcha. yeah i think the main thing is that we don't want cmp anywhere in our app (or app modules... aka design system library) and thats where this issue comes up.

[ursus]

btw cmp with just an android target is just android, its not some abstraction, so there is 0 downside

[Colton Idle]

yep. that was my reasoning with the team to go that route. it just resolves to androidx anyway. the only downside is maybe slightly slower update to newer versions of androidx.compose. but by virtue of depending on cmp in our build files, people would think its cmp and so no mention of cmp in our codebase allowed.