vinumeris / updatefx Goto Github PK

Let's say I'm packaging my first initial version with JRE 8u60.
Ship this version in a dmg format.

Then, a user downloads this dmg but her JRE is JRE 7.
This dmg will still work nevertheless because the runtime is already "inside" the app.

Then, there's a new update. Based on the docs, the update format is in jar format.

What happens when the user downloads this update? Which JRE will be used by this latest jar?

I mean, this code UpdateFX.restartApp() is basically executing a jar file. Then I'm assuming this updated version of jar will use whatever JRE installed.
Is this correct?

Currently UpdateFX is not in any dependency repo.

When running the app for the first time i get the following exception:

java.nio.file.NoSuchFileException: /home/user/.local/share/MyApp/1.jar
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
at java.nio.file.Files.newByteChannel(Files.java:361)
at java.nio.file.Files.newByteChannel(Files.java:407)
at java.nio.file.Files.readAllBytes(Files.java:3152)
at com.vinumeris.updatefx.Updater.processDownloadedUpdates(Updater.java:187)
at com.vinumeris.updatefx.Updater.processSignedIndex(Updater.java:121)
at com.vinumeris.updatefx.Updater.call(Updater.java:83)
at com.vinumeris.updatefx.Updater.call(Updater.java:33)
at javafx.concurrent.Task$TaskCallable.call(Task.java:1423)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:745)

How to integrate, etc.

Hi

The build for version 1.6-Snapshot doesn't seem to work:

[ERROR] Failed to execute goal on project updatefx-examples: Could not resolve dependencies for project com.vinumeris:updatefx-examples:jar:1.6-SNAPSHOT: Failed to collect dependencies at com.vinumeris:updatefx:jar:1.6-SNAPSHOT: Failed to read artifact descriptor for com.vinumeris:updatefx:jar:1.6-SNAPSHOT: Failure to find com.vinumeris:updatefx-parent:pom:1.6-SNAPSHOT in https://oss.sonatype.org/content/repositories/snapshots was cached in the local repository, resolution will not be reattempted until the update interval of sonatype-nexus-snapshots has

This allows the app to:

• Show a short description of an update as it's being downloaded
• Decide how noisy to make the update UI, e.g. should it be entirely silent for minor unimportant upgrades or should it block the UI entirely for critical security fixes?
• Misc other stuff in future

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)

Currently it always launches the latest version. Users should be able to pin themselves to a particular version, either because they know an update is coming that they don't want, or because they want to downgrade.

Probably we should just store a prefs file in the configured data directory.

When using v1.5 or the latest master I get the following error:
09:43:02.915 [JavaFX Application Thread] ERROR io.bitsquare.app.UpdateProcess - Update failed: com.google.protobuf.InvalidProtocolBufferException: Protocol message end-group tag did not match expected tag.
com.google.protobuf.InvalidProtocolBufferException: Protocol message end-group tag did not match expected tag.
at com.google.protobuf.InvalidProtocolBufferException.invalidEndTag(InvalidProtocolBufferException.java:94)
at com.google.protobuf.CodedInputStream.checkLastTagWas(CodedInputStream.java:124)
at com.google.protobuf.AbstractParser.parsePartialFrom(AbstractParser.java:202)
at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:217)
at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:223)
at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:49)
at com.vinumeris.updatefx.UFXProtocol$SignedUpdates.parseFrom(UFXProtocol.java:3622)
at com.vinumeris.updatefx.Updater.downloadSignedIndex(Updater.java:92)
at com.vinumeris.updatefx.Updater.call(Updater.java:83)
at com.vinumeris.updatefx.Updater.call(Updater.java:33)
at javafx.concurrent.Task$TaskCallable.call(Task.java:1423)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.lang.Thread.run(Thread.java:745)

v1.2 works but I need the fix for 8u40 - libpackager.dylib issue

Update error: java.io.FileNotFoundException: http://localhost:8000/index
java.io.FileNotFoundException: http://localhost:8000/index
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1835)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1440)
    at com.vinumeris.updatefx.Updater.downloadSignedIndex(Updater.java:83)
    at com.vinumeris.updatefx.Updater.call(Updater.java:73)
    at com.vinumeris.updatefx.Updater.call(Updater.java:33)
    at javafx.concurrent.Task$TaskCallable.call(Task.java:1423)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.lang.Thread.run(Thread.java:745)

"index.html" perhaps?

a la Chrome.

The download/updater code supports it but the index preparation tool doesn't have a workflow for merging signatures yet.

I've tried to use on Mac but it doesn't work. I think it's because of this code in UpdateFX

if (os.contains("mac")) {
// Returns path to the .app directory, which normally contains only a Contents directory.
List exes = Utils.listDir(appInstallDir.resolve("Contents/MacOS"));
if (exes.size() != 1)
throw new IllegalStateException("Found unknown number of app executables");
return exes.get(0);

In fact, in my "MacOS" folder I have two file, the current application and another named "libpackager.dylib". So there is not one file..

I'm running with Jdk8u40 bundled app btw

Is it normal?

It's unclear exactly what should be displayed on the screen for this, but a (truncated?) hash of the post-update JAR is probably right. At any rate keeping the keys inside a hardware device is an improvement even if the message on screen is a bit hard to verify.

Will wait to see how Jim/Gary get along with multibit hardware support before experimenting with this. Might be a crowdfunded project.

Could be that the app itself already uses the same path to store its own data, extending the path with a unique folder for the new versions will make it much cleaner

A no-op update is currently half a megabyte for Lighthouse. Most likely this is due to the timestamps in the JARs, every update modifies every timestamp. It can also be due to trying to delta patch a compressed file. Switching to uncompressed JARs on disk with zeroed out timestamps would most likely make updates a lot smaller with no real impact on app download time.

Should be $java -jar updatefx-app-1.0.jar --url=http://localhost:8000 /path/to/working/dir