<@U0BDMQTHS> is there an easy way to add conveyor ...
# compose-desktop
h
@mikehearn is there an easy way to add conveyor to an existing compose project? or do i have to generate a blank one with conveyor and copy my code over?
m
Sure, it's only the config file that matters. You can also just write a conveyor.conf file yourself, and add the gradle build plugin. There's no need to copy files around. The blank sample project may be useful as a guide
h
thanks, and to make the auto dependency thing work, what exactly do i include in the config?
i tried conveyor make app with basically the default config and its 500+mb 😂
is it just jvm.modules = [ detect ]?
dont think that worked
@mikehearn pls help 🙏 also im using some libraries that i guess use some other external dependencies, and gradle seems to fetch them so running my app from the IDE works fine. but after packaging with conveyor, it seems they didnt get included so i get an error like in the image. do i need to manually include those after packaging or is there a way to tell conveyor to include it? im also using javacv which comes with ffmpeg, so im guessing a similar thing would occur there with it not being automatically included
m
[ detect ]
is the default already.
For native libraries on the JVM, see https://conveyor.hydraulic.dev/12.1/configs/jvm/#native-code to understand what might be going on
Conveyor will extract native libraries from JARs when it's allowed to, and ensure they can be found using
System.loadLibrary
, otherwise it'll leave them alone and your app will be expected to extract them at runtime to a temp dir like during development.
If your app isn't finding a native lib, check the
app.jvm.extract-native-libraries
key to see if it's true, try setting it to false (which has other downsides but may help you get started). Otherwise run
conveyor make windows-app
and poke around to see where the DLL is being put, if at all, and make sure the way your app is loading the DLL will be able to find it. The
java.library.path
property is being set such that DLLs can be found, usually.
BTW we are in Central European Time so won't reply at night 🙂
You should also make sure that if the native code is in dedicated jars/maven coordinates, that you include those using the machine specific Gradle configurations
e.g.
Copy code
dependencies {
    windowsAmd64("org.example:javacv:1.2:win32")
}
h
thanks, ill try those things out. about the package size, for example im using
Copy code
implementation(compose.materialIconsExtended)
and just using a couple icons from it like Icons.Default.{some icon} is it normal then that in the conveyor output app (non installation version) it is including a 35mb jar file
material-icons-extended-desktop-1.5.10.jar
shouldnt it just extract the definitions of the few icons im using and ditch the rest?
m
Yes. Conveyor doesn't do dead code elimination for you except for using jdeps to minimize the jdk itself. You could reduce the size by using ProGuard. The Compose for Desktop gradle plugin has some support for that.
It's a separate thing to Conveyor partly because it can easily break apps, you'd need to configure it explicitly and iterate on the config to ensure all the code needed was being kept (e.g. if accessed via reflection).
h
is that something that is usually done? i have no experience whatsoever with actually packaging an app of any kind. just seems a bit alarming that it came out to 500mb lol
m
It varies. Most of our users don't bother, I think. It really depends on how bandwidth/latency sensitive your users are. If it's a specialized app, well, a lot of apps are quite large these days so they'll suck it up. If you're doing something where every second counts for new users then yes you should optimize for space.
h
i mean not that it really matters, its just a small personal project. and i guess itd be ok if it were 100-200mb, but 500mb feels a bit over that "this is normal" limit and kinda just feels like ive done something wrong. ill take a look at proguard
just to clarify, is proguard something id use before or after packaging with conveyor? are they even compatible like that?
@mikehearn does running conveyer make app-windows actually incorporate changes i made to my code? i understand it uses caching but im making changes, running that command and its not being reflected in the output binary. if i use --rerun then the changes appear. do i have to use rerun every time?
actually it appears even rerun doesnt seem to be capturing changes to my code? e.g. i changed a text element that usually shows a timer to just show the text "abc" but after using
conveyor make windows-app --overwrite --rerun
it still shows the timer, even though running from IDE shows "abc". Am i doing something wrong? im really lost atm
m
It won't rerun Gradle for you at this time. So you'd need to run
./gradlew jar
first or equivalent to do a build. We might add support for rerunning the build system in a future version