ZipException when using updatefx-app

[manuel-mauky]

I'm getting a java.util.zip.ZipException when following your step-by-step tutorial:

$ java -jar updatefx-app-1.5.jar --url=http://localhost:8000 .
Enter signing key password:
Processing .\builds\1.jar
Exception in thread "main" java.util.zip.ZipException: invalid entry compressed size
(expected 2 but got 5 bytes)
        at java.util.zip.ZipOutputStream.closeEntry(Unknown Source)
        at com.vinumeris.updatefx.tools.ProcessZIP$Companion.process(ProcessZIP.kt:42)
        at com.vinumeris.updatefx.tools.UFXPrepare$Companion.processBuild(UFXPrepare.kt:294)
        at com.vinumeris.updatefx.tools.UFXPrepare$Companion.main(UFXPrepare.kt:152)
        at com.vinumeris.updatefx.tools.UFXPrepare.main(UFXPrepare.kt)

[ghost]

Same is happening with me too. I am using the 1.5 version of the app with java version "1.8.0_45"

[mikehearn]

Hey guys,

Sorry about this. I've been distracted lately with other things. I'll try and make space to investigate soon. How did your 1.jar zip get built? Is it actually indeed a valid zip file?

[manuel-mauky]

How can I verify if its a "valid" zip file? At least I can open it with the 7Zip application so I assume it's valid.

My jar file is created by a gradle build using the shadow plugin (which is similar to mavens shade plugin).

Is there a possibility to use updatefx without packaging all dependencies in one single "fat-jar"? In some use cases (like using CDI/WELD for dependency injection) using shadow/shade plugin is causing problems because files with the same name/path will be overwritten in the resulting jar file.

[mikehearn]

Re: files being overwritten. That shouldn't matter because the files should be identical anyway. If they are NOT identical then you have a very unstable situation because you presumably have two components that expect the same class to behave differently. Use the maven enforcer plugin or gradle equivalent to check that you don't have such version conflicts.

OK, I haven't used the gradle plugin, but it'd be weird if it was different.

You can use UpdateFX without the bundling, but then it's up to you to ensure the javapackager puts all the needed jars on the classpath and, of course, they then cannot be updated.

[manuel-mauky]

The problem is not so much for classes but for configuration files. For example CDI/Weld searches for all JAR-files on the classpath that have a 'META-INF/beans.xml' file in them. It ignores all other jars. This doesn't work anymore if JAR files are merged. Another example is logging configuration files. But this is off-topic anyway. ;-)

I think with a little hacking this should be possible with gradle/maven:

1. build the application jar
2. put it into your updatefx tool to create the modified jar
3. put the modified jar together with the dependencies into the javapackager/javafx-plugin

Of course, as you say, this way dependency jars couldn't be updated.

[mikehearn]

Ah, I see. I don't have any experience with Weld.

Really, I need to go back and do some proper UpdateFX hacking to make a version 2. It would:

• Be able to update different JARs individually.
• No longer calculate deltas over the JAR files (I thought this would work better than it does), but rather, calculates deltas over their contents.

That should make updates much smaller and faster still. However, the multi-jar thing would presumably complicate class loading.

[ghost]

I pulled the source, I commented out line 37: output.setLevel(0) in https://github.com/vinumeris/updatefx/blob/master/app/src/main/java/com/vinumeris/updatefx/tools/ProcessZIP.kt, packaged, and it ran fine. Not sure what other implications this might have though.

[mikehearn]

Less efficiency, basically (larger patches). You may not care about this.