Java 1.6
Hello,
I have read the posts regarding packaging JRE. So, I have a couple of questions regarding JRE 1.6 and hopefully will be allowed to ask them in this single post.
First, I am somewhat confused by the various posts. I took from the posts that there are at least 2 methods for packaging JRE, java 1.6. I need some advise when to use one and not the other.
Method 1: Involves modifying deployement.properties and the deployment.config contents.
Method 2: Involves modifying using a package editor, I used WPS, to change the property values of:
IEXPLORER -> 1
JAVAUPDATE -> 0
AUTOUPDATE -> 0
JU -> 0
MOZILLA -> 1
SYSTRAY -> 1
EULA Keep the value of 0, else the java fails to run properly after install.
Question 1: Is this correct, are these two different approaches to packaging JRE?Is method 1 used when you do not want to use a msi editor such as WPS or Orca? I kind of figure both methods could even be combined into a single package technique but not sure when combining them would be good practice.
Question 2, Is in regard to a my using method 2. I opened the extracted JRE MSI in WPS with the editor and modified the above properties. I saved the modified msi into the folder with the previous extracted mst, install.cfg and various log files.
Runnning the following cmd, msiexec.exe /i <msi Path>\File.msi /q, installs jre 1.6 and works fine when deploying to a PC which does not have java on it. But, fails if java is already installed when the command runs. The old version gets uninstalled but 1.6 does not install. How do I get 1.6 to install after uninstalling the already installed version?
Thanks Brad
I have read the posts regarding packaging JRE. So, I have a couple of questions regarding JRE 1.6 and hopefully will be allowed to ask them in this single post.
First, I am somewhat confused by the various posts. I took from the posts that there are at least 2 methods for packaging JRE, java 1.6. I need some advise when to use one and not the other.
Method 1: Involves modifying deployement.properties and the deployment.config contents.
Method 2: Involves modifying using a package editor, I used WPS, to change the property values of:
IEXPLORER -> 1
JAVAUPDATE -> 0
AUTOUPDATE -> 0
JU -> 0
MOZILLA -> 1
SYSTRAY -> 1
EULA Keep the value of 0, else the java fails to run properly after install.
Question 1: Is this correct, are these two different approaches to packaging JRE?Is method 1 used when you do not want to use a msi editor such as WPS or Orca? I kind of figure both methods could even be combined into a single package technique but not sure when combining them would be good practice.
Question 2, Is in regard to a my using method 2. I opened the extracted JRE MSI in WPS with the editor and modified the above properties. I saved the modified msi into the folder with the previous extracted mst, install.cfg and various log files.
Runnning the following cmd, msiexec.exe /i <msi Path>\File.msi /q, installs jre 1.6 and works fine when deploying to a PC which does not have java on it. But, fails if java is already installed when the command runs. The old version gets uninstalled but 1.6 does not install. How do I get 1.6 to install after uninstalling the already installed version?
Thanks Brad
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
anonymous_9363
15 years ago
- It is almost universally accepted that directly editing vendor-supplied MSIs is A Bad Thing. Use transforms.
- I found that using the properties was a bit hit-and-miss, whereas the 2 deployment files worked every time.
- I'm surprised that the "old version" gets uninstalled, since JREs are designed to live side-by-side.
- I found that using the properties was a bit hit-and-miss, whereas the 2 deployment files worked every time.
- I'm surprised that the "old version" gets uninstalled, since JREs are designed to live side-by-side.
Posted by:
brdbreath
15 years ago
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.