New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update windows packaging process #2163

Merged
merged 5 commits into from Jan 7, 2019

Conversation

Projects
None yet
3 participants
@devinbileck
Copy link
Member

devinbileck commented Dec 22, 2018

The 64bitBuild.bat script has been renamed to package.bat and has
been updated so that it is capable of performing the complete packaging
process without having to rely on the jar first being built and prepped
from the MacOS scripts. However, it does support having the jar
previously built and prepped and will look for a prepped jar in the
desktop/package folder. If not found, it will build and prep it
prior to packaging the executable.

Additionally, some unnecessary options that were being passed to
javapackager.exe have been eliminated such as BappVersion and Bruntime.
AppVersion is now being passed via environment variables and the
Bruntime option is valid only when the -native option is set to jnlp.

The Bisq.iss file was changed so it no longer needs to be updated with
AppVersion every time as it is being passed from package.bat via
environment variables. Also, AppCopyrightYear does not need to be
updated as it is determined automatically. A few other options were
added or tweaked as well.

Finally, a release.bat script has been added that will perform the
release process of copying necessary files to a versioned release folder
and generating/verifying signatures. Linux and MacOS packaged installers
should be copied to their appropriate package folders prior to
executing this script if they are to be included in this release
process, otherwise only the Windows files will be included.

The MacOS and Linux packaging scripts should be reviewed and updated
accordingly.

Update windows packaging process
The 64bitBuild.bat script has been renamed to package.bat and has
been updated so that it is capable of performing the complete packaging
process without having to rely on the jar first being built and prepped
from the MacOS scripts. However, it does support having the jar
previously built and prepped and will look for a prepped jar in the
desktop/package folder. If not found, it will build and prep it
prior to packaging the executable.

Additionally, some unnecessary options that were being passed to
javapackager.exe have been eliminated such as BappVersion and Bruntime.
AppVersion is now being passed via environment variables and the
Bruntime option is valid only when the -native option is set to jnlp.

The Bisq.iss file was changed so it no longer needs to be updated with
AppVersion every time as it is being passed from package.bat via
environment variables. Also, AppCopyrightYear does not need to be
updated as it is determined automatically. A few other options were
added or tweaked as well.

Finally, a release.bat script has been added that will perform the
release process of copying necessary files to a versioned release folder
and generating/verifying signatures. Linux and MacOS packaged installers
should be copied to their appropriate package folders prior to
executing this script if they are to be included in this release
process, otherwise only the Windows files will be included.

The MacOS and Linux packaging scripts should be reviewed and updated
accordingly.
@devinbileck

This comment has been minimized.

Copy link
Member

devinbileck commented Dec 22, 2018

I will review and update the Linux packaging scripts next.

@devinbileck

This comment has been minimized.

Copy link
Member

devinbileck commented Dec 22, 2018

Note, signing the Windows installer (#1952) is still on my TODO list.

@devinbileck devinbileck referenced this pull request Dec 29, 2018

Closed

For December 2018 #187

@ManfredKarrer

This comment has been minimized.

Copy link
Member

ManfredKarrer commented Dec 29, 2018

@ripcurlx Can you review that PR? I am on holiday untill January.

@ManfredKarrer ManfredKarrer removed their request for review Jan 1, 2019

@ripcurlx
Copy link
Member

ripcurlx left a comment

@devinbileck Sorry for my late review. I was also off most of the time and had a cold on top.
Similar to my remarks here, could you please update

cp $EXE_JAR "$win64/Bisq.jar"
as well, so it works within the current build process?

@ripcurlx

This comment has been minimized.

Copy link
Member

ripcurlx commented Jan 7, 2019

Requested changes merged in #2190

ripcurlx added some commits Jan 7, 2019

Merge branch 'master' of github.com:bisq-network/bisq into update-win…
…dows-packaging-process

# Conflicts:
#	desktop/package/windows/Bisq.iss
@ripcurlx

This comment has been minimized.

Copy link
Member

ripcurlx commented Jan 7, 2019

@devinbileck Could you please check if my merge in 3d2817e is correct?

ripcurlx added some commits Jan 7, 2019

@ripcurlx ripcurlx merged commit 77338c7 into bisq-network:master Jan 7, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@devinbileck

This comment has been minimized.

Copy link
Member

devinbileck commented Jan 8, 2019

@ripcurlx Sure, I will review and test your changes.

@devinbileck

This comment has been minimized.

Copy link
Member

devinbileck commented Jan 8, 2019

@ripcurlx The merge looks fine. However, a few comments to other commits:

  1. The iss file requires the BOM since it contains unicode messages. Otherwise they will not be displayed properly within the installer for those languages. See https://stackoverflow.com/a/49923030/8871018. Not sure why you are encountering issues? (worked for me with Windows 10)
  2. My intention with overriding JAVA_HOME was to simplify the process, rather than the user having to set JAVA_HOME before to OracleJDK, and then change it back afterwards to OpenJDK (its a pity packagemanager is not available in OpenJDK). I agree hard coding the path in the script makes it inflexible in case the user has it installed elsewhere, and they may need to edit it. But, I was considering investigating installing OracleJDK as part of the install_java script and we can have a standardized path (again, a pity that archived Java versions require a user account to download the JDK). I suppose an alternative solution is to use a different variable name within the script and check if the path exists first, else use JAVA_HOME environment variable.
@ripcurlx

This comment has been minimized.

Copy link
Member

ripcurlx commented Jan 8, 2019

@devinbileck

  1. I just removed the BOM as Windows complained during the build that it doesn't like this character in the beginning of the file. You don't see this error when running the script?
  2. This was the reason why I removed it as I had a different installation directory on Linux. I removed it from Windows just because of consistency in that case. But yes, we could do some workaround with checking for the javapackager.
@devinbileck

This comment has been minimized.

Copy link
Member

devinbileck commented Jan 8, 2019

  1. No, worked fine for me. I will give it a try again.
  2. I will see what I can do.

@devinbileck devinbileck deleted the devinbileck:update-windows-packaging-process branch Jan 8, 2019

@devinbileck

This comment has been minimized.

Copy link
Member

devinbileck commented Jan 8, 2019

  1. @ripcurlx What is the error that you encounter?

As a result of it now missing the BOM, I just tried the v0.9.3 release installer on Windows 7 French and the custom messages are not displayed properly.

Launch the installer with the application running:
image

Comment text within the control panel:
image

Note, this issue will only affect the custom messages contained within the Bisq.iss file, not the general translations within the installer.

Once I added the BOM, the translations above were shown properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment