We bundle the Java 6 JRE with our application installer so that it can be run on any machine, but this makes the application a little bit heavier. So we are planning to reduce the size of the JRE. If anyone has done this sort of task, can you please provide guidance to move forward with this?
Look at the README file in the JRE directory. The 'Optional Files and Directories' section lists a number of files that can be removed from the Oracle/Sun JRE if you are packaging it with your application.
I use an Ant buildfile to copy the JRE from the system install location to the package directory when creating an installation. Put the list of files you want excluded in a separate file and use the 'excludesfile' attribute to load this list:
<copy todir="${deployed_jre_dir}">
<fileset dir="${system_jre_dir}" excludesfile="jre_excludes.properties"
</copy>
Sample jre_excludes.properties file:
# per the README from the JRE, these files are for the browser plugin and are not needed otherwise
#bin/javaw.exe
bin/javaws.exe
bin/javacpl.exe
bin/jucheck.exe
bin/jusched.exe
bin/wsdetect.dll
bin/NPJPI*.dll
bin/NPJava*
bin/NPOJI610.dll
bin/RegUtils.dll
bin/axbridge.dll
bin/deploy.dll
bin/jpicom.dll
bin/javacpl.cpl
bin/jpiexp.dll
bin/jpinscp.dll
bin/jpioji.dll
bin/jpishare.dll
lib/deploy.jar
lib/plugin.jar
lib/javaws.jar
lib/javaws/messages*
lib/javaws/miniSplash.jpg
bin/new_plugin**
bin/jureg*
bin/ssv*
bin/jqs*
bin/jp2*
lib/deploy/**/*
# if you do not need any RMI stuff
# wildcard to catch .exe files on Windows
# note rmi.dll is not excluded, which is needed by jconsole; add rmi.dll if you do not need jsonsole
bin/jbroker*
bin/java-rmi*
bin/rmid*
bin/rmiregistry*
bin/tnameserv*
bin/orbd*
bin/servertool*
# do not include QuickTime
# this will be in the jre dir for machines that have QT installed
lib/ext/QTJava.zip
Some update info: since java 8 there is an official Oracle tool called jrecreate for creating of small embedded JRE packages.
For my Java 8 Update 144 desktop application I exclude the 2 big Java FX files:
bin/jfxwebkit.dll // ~34 MB unpacked
lib/ext/jfxrt.jar // ~17 MB unpacked
The zipped jre is 49 MB instead of 66 MB.
For me this is an acceptable tradeoff between reduced size and added build complexity (and potential bugs).
You're trying to reduce a standard JRE's size? Don't do that. You can choose to bundle an alternative JRE which might be smaller. A list can be found on this Wikipedia page. As always, beware of compatibility issues and test your application thoroughly.
An other, and safer, way is to just require an installation of a JRE on the target machine.
You can use jlink tool to post-process JDK and create a smaller image by keeping only a specified set of JMPS modules and debug information. This is a common practice right now as we are using more containerized environments.
Related
When I performed a release build of Chromium in a Windows environment according to the following procedure, the file size was 48GB.
https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md
However, the file installed using the Chrome installer is about 700MB.
Is there a build option to output the minimum required files for browsing?
The build options currently in use are:
gen gen out/Default --args="is_debug=false enable_nacl=false symbol_level=0 blink_symbol_level=0 is_component_build=true"
autoninja -C out/Default chrome
You are using is_component_build flag which will build many shared libraries to avoid the long linkage time, if it's not specified. You can just remove that flag, then it will be automatically set to false. That should minimize the number of files output during the compilation process.
Also your build folder includes debug symbols and other files thereby increasing the build folder's size to a few GBs. Generally even for highly optimized release build, it's greater than 20 GB and for debug build it's around 80-100 GB.
So, you should not be comparing the build folder size with the installation folder size. Also, mini_installer will greatly reduce the size of your Chromium fork while distributing your app. So you should consider making an installer for your Chromium fork for distribution to end-users.
We are working on a a system that uses cloud runner, where we have a tech like Spring + Gradle plus Mongo.
The system is containerized and runs on cloud-run in gcp. However, gcp has a hard limit of 2gb on container size, which we are trying to fit into, as of now.
Upon deeper investigation, I found that, the gradle wrapper that we use downloads at least 170mb extra than what we needed.
It includes following -
It contains documentation, which is not needed while running a build via wrapper.
It does not delete the zip file after extracting the same..
Together it counts to 270 mb, which quite big for us.. What I want to know is, Is there any wrapper configuration OOTM that will help me avoid these extra files being downloaded on our system?
It seems you used the Gradle distribution type "all", which includes source code and the Gradle documentation (e.g., for IDE support -- source).
Since you run the Gradle wrapper in the cloud, you probably do not require IDE support: Use distribution type "bin". At least in latest versions of Gradle (version 7) this is the default, but you can still be explicit to make sure:
# gradle wrapper --gradle-version 7.0.2 --distribution-type bin
The size difference is about 200 MB:
# du -hs ~/.gradle/wrapper/dists/gradle-7.0.2-{all,bin}
438M ~/.gradle/wrapper/dists/gradle-7.0.2-all
229M ~/.gradle/wrapper/dists/gradle-7.0.2-bin
Gradle still keeps the zip-file, so you will have to delete that manually.
For us, this what we went with.
Although we used gradle wrapper, We also made sure that we install relavent gradle wrapper upfront on the machine, so that when we run gradlew command, we dont download it again.
When you download gradle wrapper while building image, you have liberty to delete the file from the filesystem while building container image. So you can free up some space.
Next step is you can squash the image to remove all unnecessary layers. How can i remove layers from my docker image?
Is it possible to make a WiX installation bundle with size of total .msi's and exe's inside bundle more than 2GB? Currently in my .wxs template I have a <chain> inside of a <bundle> that contains multiple <MsiPackage>'es. I haven't created that WiX template on my own, I'm just improving/fixing bugs in a legacy project, so I am not very proficient with the WiX toolset. Anyway, then I create a .wixobj out of that .wxs template with candle.exe and this .wixobj I feed to light.exe. It seems that if total size of content to link is more than 2GB light.exe fails with error:
error LGHT0306 : An error (E_FAIL) was returned while finalizing a CAB
file. This most commonly happens when creating a CAB file with more
than 65535 files in it. Either reduce the number of files in your
installation package or split your installation package's files into
more than one CAB file using the Media element.
I looked for solution and one suggestion was to use <MediaElement> but that one is only available in a <product> tag which I guess I cannot use in my situation, because the bundle that I am cooking has a custom bootstrapper embedded, and as far as I understood wix product template is not about bootstrapper applications. Another opinion that I found was that you can't create WiX bundle with size of single package more than 2GBs, but that is not exactly my case, because each package I am bundling is no more than 700MBs.
I have already tried separating <MsiPackage>s into <PackageGroup>'s in separate <Fragment>'s which was referenced in <Bundle>'s <chain> in <PackageGroupRef>, but it didn't help, light.exe throws the same error. I have also found a suggestion to try to put packages into separate <Container>s in <bundle>, but I didn't manage to try it because I didn't understand how to do it, WiX bundle documentation just mentions that the are some containers but never actually gave an advice on how to use them.
I am using WiX 3.11
UPD: I just wanted to add some clarifications.
My goal is to make a bundle what would be a single .exe file with all related .cab's and other stuff embedded into the final bundle, so delivering bundle that consist of .exe bootstrapper and multiple external .cab file isn't really a preferred option even though it might be x times faster unless this is the only solution in my case.
UPD 2:
It seems that yet you can assemble a bundle with 2 GBs + size, it won't start. Maybe because the output executable is x86, and windows can't launch x86 executables over 2gbs size. I didn't manage to make an x64 bundle, maybe that would work, but I never found how to do it. Guess the only option is to let users download missing content and make bundle only contain essential parts. Thanks everyone for help.
Compressed bundles cannot be bigger than 2GB. Burn supports containers up to 2GB each and only one container can be attached to the bundle .exe itself.
Bob's answer is still correct for v3.
Support for multiple attached containers was recently added in v4 (#6144). That allows a single file bundle to be larger than 2GB. v4 also added support for x64 (and ARM64) bundles, which allows the bundle to be larger than the x86 maximum.
A related open feature request is #6521 where WiX would automatically split payloads across containers so that the user doesn't have to manually create new containers to avoid the cabinet limitations for size or number of files.
I'm using buildroot to create a linux system for raspberry pi. I want to use the initramfs to enable to system to self-patch. The procedure roughly runs as follows:
Raspi boots, kernel loads initramfs
The initramfs-system (which contains busybox, zsync etc.) connects to a central server and checks if there are boot-file updates available (e.g. a new kernel)
If not, it checks if there is a system update available and downloads that if needed
The downloaded (squashfs) system image is mounted and executed via switch_root
My problem is that I need to compile a secondary busybox (and some more packages) for the initramfs which do not belong in the main system. I currently solved this by manually tinkering with the package files to install into target/initramfs, moving this folder out with pre-build and back in again with post-build, but this seems rather hacky. Additionally, different package types require different types of changes. Is there a better solution to this problem? If one could for example manually overwrite the target directory for each package, this problem would be rather easy to solve.
Create two separate buildroot configurations.
One configuration will have the kernel and the initramfs.
The other configuration only has the squashfs rootfs.
Creating a partial rootfs from a configuration is very tricky, because you have to be sure that you don't miss any shared libraries or other auxiliary files needed by some program.
Note that to speed up the build, you can use ccache and/or use an external toolchain. See the manual.
Our application is distributed as a zip file, with a small bat/shell script that the user runs after extracting the archive to install the application. This zip file is currently created via mavens assembly plugin.
The zip file we distribute contains a lib folder with an executable jar, as well as all the files we need as part off the deployment off the actual application.
What we want is a self extracting zip-file that executes that contained bat file after the zip file has been extracted. And this should be created as a part off the build process.
I have read creating-a-self-extracting-zip-archive-on-a-linux-box, and can do that. But I don't see anywhere how to also execute a bat file within the extracted archive when it's done.
I have found winzip self-extractor, but I would prefer something that can be run on any platform. The build server and some developers use linux. I also found some VB code which leads me to believe that there might be some autorun properties on zip files.
Did you consider using IzPack (and the IzPack Maven Plugin) to generate a cross-platform installer?
The previous replier suggested lzpack, it's documentation contains the following pointer:
""The 7-Zip project (see http://www.7-zip.org/) provides a so-called SFX for installers, i.e., an image that can be use to create self-extracting Windows executables. Once its content has been extracted, such a self-extracting executable can launch an executable or a file. In the later case, it is assumed that there exists an association between a file extension and a software component.""
7-zip is cross platform, although I haven't tried whether you can build sfx files for windows on linux.
The 7zip manpage says you can do this.
EXAMPLE 2
7z a -sfx archive.exe dir1
add all files from directory "dir1" to SFX archive
archive.exe (Remark : SFX archive MUST end with
".exe")
While it's a bit late:
We just released a Maven plugin that can do this (docs at https://zephyr.sunshower.io/site/). It's free, open-source, and permissively licensed.
We bundle a JRE with our application using this plugin, then launch an IzPack installer with that JRE. It also supports code-signing, which we expect to have documented within the week.