I'm looking again into Hydraulic Conveyor to creat...

# compose-desktop

[Stefan Oltmann]

I'm looking again into Hydraulic Conveyor to create an updateable setup of my macOS JVM app.

Is there a sample for a multi-module Jetpack Compose app? The sample app created by conveyor generate just has one module.

I tried to modify my app based on what I see in the sample, but I get all kinds of strange errors.

For example I deal with Could not read Jetpack Compose configuration, likely plugin version incompatibility? which comes from NoClassDefFoundError: org/jetbrains/compose/ComposeExtension

[Stefan Oltmann]

My app has a similar structure to https://github.com/JetBrains/compose-multiplatform-template

I will see if I can reproduce that problem here.

[Michael Paus]

One problem probably is that the recommended structure has constantly changed in the past. I take the structure generated by the KMP wizard from Jetbrains as the current reference. See: https://www.jetbrains.com/help/kotlin-multiplatform-dev/compose-multiplatform-create-first-app.html The reference that you linked to is already archived probably because it is considered outdated.

[Stefan Oltmann]

Yes, but as long as it's working I can't change my projects structure every week. 😄

[Stefan Oltmann]

I may have found it...

Conveyor does not like my jvm("desktop")
Task with name 'jar' not found in project ':desktopApp'.

[Alexander Maryanovsky]

You can tag Mike Hearn, the author, if you’re stuck.

[Stefan Oltmann]

@mikehearn It doesn't work with jvm("desktop"), right?

[Mike Dawson]

I am using conveyor successfully with a multi module project. I followed the instructions as per the conveyor tutorial (turtoise path) : https://conveyor.hydraulic.dev/13.1/tutorial/tortoise/1-get-started/ . My conveyor.conf file is here: https://github.com/UstadMobile/UstadMobile/blob/primary/conveyor.conf

[Stefan Oltmann]

Thanks, Mike, that's helpful.
I noticed that your Desktop App is kotlin("jvm"), not kotlin("multiplatform")
Looks like Conveyor has some difficulties with the multiplatform plugin. 🤔

https://github.com/UstadMobile/UstadMobile/blob/primary/app-desktop/build.gradle.kts

[Mike Dawson]

The app module, yes that is JVM as per the compose template of the time. The app-desktop has very little in it. I put the screens in another module (lib-ui-compose), which is multiplatform, shared between my Desktop and Android app

[Stefan Oltmann]

Okay. That lib-ui-compose defines jvm("desktop") like I do, but it has no conveyor plugin added

[Stefan Oltmann]

I currently suspect Conveyor failing on multiplatform plugin with renamed JVM sourcesets.

[Stefan Oltmann]

I take this as a chance to remove the name. My libs already have the more standard jvmMain & jvmTest

[Stefan Oltmann]

I think it was jvm("desktop"), because the template I started Ashampoo Photos on was just that 😄

[Mike Dawson]

I have found many times on Android where Android stuff would not play nice in multiplatform land, so that brought me to the approach of putting shared stuff in modules and having a single platform module for each target

[Stefan Oltmann]

Android as multiplatform works for me right now, but I fully agree with you. It's safer to do so. Plugins seems to struggle with that

[Stefan Oltmann]

Another example that shows that Conveyor does not work properly with multiplatform projects is that I needed to set this:

version = rootProject.version

[Mike Dawson]

Not sure if that's conveyor's fault - why should there be any difference in reading the project version property?

[Stefan Oltmann]

It seems to check if the current project has it's "version" set and fails otherwise.
From a multi module project aware library I would expect it to check for the rootProject version if the module hasn't one set.

[Michael Paus]

If you should get that working, it would be nice if you could summarise your findings here 🙏.😇

[Mike Dawson]

It does work for me ; all my 'executable' versions (Android APK/AAB, desktop app, and Kotlin/JS version) are separate modules because I found that many Android Gradle things/plugins don't play nice in a multiplatform build.

All I had to do for conveyor was to put in the module path (e.g. app-desktop) in a few places (e.g. prefix for the gradle task, resource paths, etc), and everything was fine.

Conveyor also has an active discord server.

[Mike Dawson]

I have asked a few questions on the Discord server where needed... most things seem to be answered by their own team / creators.

[Mike Dawson]

... quite quickly

[Stefan Oltmann]

Ok, I will go there.
The creator did not respond to me on this Slack and conveyor is broken for my project.

[Stefan Oltmann]

There is also not so much activity.

However I think I see what also breaks the plugin.

It relies on the output of ./gradlew -q printConveyorConfig

But if my Gradle scripts do some logging (using println() or logger.quiet()), it breaks.

It should really start reading it's output after
// Generated by the Conveyor Gradle plugin.

All in all it doesn't seem to be very mature. I now need to think about going on with Conveyor or look again for alternatives.

[Leo]

Hello, @Stefan Oltmann. Found this channel now that it was mentioned on the Conveyor Discord.

[Leo]

Mike is currently on vacation until next week, which is why he probably missed your questions here.

[Leo]

You’re right that currently the Conveyor Gradle Plugin doesn’t support renamed source sets, the “jar” or “jvmJar” are hardcoded in the plugin.

[Leo]

That can of course be improved, but we’ll need to properly design the user interface for specifying custom source set names.

[Stefan Oltmann]

Thank you, Leo 🙂

Yes, that are the improvements I see so far:
• Support renamed source sets
• Read everything after Generated by the Conveyor Gradle plugin. because otherwise a println() will break the plugin.
• Support ProGuard out-of-the-box (without manual work)

[Stefan Oltmann]

Right now I struggle to find an option for using Temurin without going the full custom JVM route.

https://github.com/StefanOltmann/conveyor-test/blob/064a31c10b5b776a9ca7ba1aedd61e1be93c4e43/conveyor.conf#L10

[Leo]

Mind if I move this to our Discord, as it’s the current official support channel?

[Stefan Oltmann]

Ok, for now.

[mikehearn]

Following up here:

• Temurin is called "Eclipse" by Conveyor and should be supported. See https://conveyor.hydraulic.dev/13.1/stdlib/jdks/#version-matrix
• The Gradle plugin for Conveyor is open source. Making it more configurable is on the list of things to do but it's more of a feature, and fixing bugs has taken priority. If someone wants to figure out the right way to wire things up and submit a PR that'd be amazing, as we sort of lost track of all the endless CMP/gradle changes a while back and I'm not sure what the right way to do it in modern Gradle is. Ditto for supporting ProGuard output. Probably, the task used to read the classpath should be configurable via a DSL.
• We should use the Gradle RPC interface to read the output of the config task rather than parsing stdout, that would fix the issue of println() stuff confusing the import.