In Install4J is it possible to update the sys.preferredJRE variable? - install4j

I have an installer whose purpose is updating the max version of a JDK for an existing installation (we require JDK, not JRE), and pointing the existing installation to run with the later version of the JDK (which is user pre-installed and user-specified).
In the installer, I have code that calls JVM.setPreferredJVM() from a directory chooser form component. According to the API for JVMSelector, it says this method will "Set the preferred JRE/JDK for your application." According to the help docs on variables (sys.preferredJRE), "This variable will only be set after the "Install files" action has run."
When I run the installer, I see that the setPreferredJVM() method is called, but the sys.preferredJRE is not set to what I wanted, it still references the old JVM. This is a problem because my subsequent "Add VM Options" steps use the sys.preferredJRE variable.
I expected that calling JVMSelector.setPreferredJVM() would update sys.preferredJRE, but it does not. How can I accomplish this so that the user can set the preferred JVM/JDK during the install?

This is a bug, it will be fixed in 6.0.2. Please contact support#ej-technologies.com to get an interim build with the fix.

Related

Is there a way to disable auto-update without re-running the installer?

We have an installer with a separately selectable auto-update feature.
Normally, if a customer wants to switch that feature on or off after the installation has completed, we tell them to re-run the installer and correct the setting. (Tested, works.)
Now a customer has a problem: Their corporate IT prepared an installation package that (mistakenly) has auto-update installed, and said IT refuses to put out a corrected installation package.
So the question is:
Can I give the customer a reasonably future-safe way to disable auto-update - say, by modifying a registry entry - without having to re-run the installer?
On Windows, the registry key
HKEY_CURRENT_USER\SOFTWARE\ej-technologies\install4j\installations
contains values with the names updateSchedule<application id>. If you locate the one for your installer, you can change the value data to "never".

Can I set a variable in the build time before the installation process in Install4j?

For each installation I would like to introduce the current version on the welcome screen. For that, I create a "Read a properties file" action which reads my application manifest.properties which exists under the distribution tree. A step later I have a "Run script" action which extracts the properties I need for the version and set it into installer variables.
My problem is that when trying to install the installer on a clean computer it throws an error since it has no distribution tree nor the manifest.properties.
Is there any elegant way to set the variables before the installation process begins, like in the build time for example?
The version of your application is configured on the "General Settings->Application Info" step. You can use it in all text properties with this syntax:
${compiler:sys.version}

Install4j add on update installer within main installer

Is it possible to bundle an add on update installer within a main installer and detect if there is a previous version present on the machine = run the add on update installer else run the main installation?
I don't think it would make a lot of sense to bundle a separate update installer. Also, an add-on installer cannot perform an update since it cannot change the installed version.
Installers know if they are performing an update or not and you can change their behavior based on that condition.
For example, in order to not execute a particular action for an update, set its condition expression to
!context.isUpdateInstallation()
If you have complex update-dependent logic for file installations, you can handle that in the "File filter" property of the "Install files" action.

How to validate an upgrade before installation

We have an eclipse feature that is licensed and the license is handled by our own code. The user can go in on our update-site and upgrade his feature. The problem we face is when the user's license needs to be updated before he can use the new upgrade.
What I want to do is to validate the feature version against the users license and warn the user that his license needs to be updated before he install.
I thought I would do this using a custom eclipse p2 touchPoint action validateLicense.
Example:
My code is called, where I validate the version against the user's license. If it fails I warn the user and he can then cancel the installation.
So my first question is:
Do I get this right, or is it some other way to do this?
My second question is pretty basic:
Where do I tell eclipse to run my code?
I have looked here at eclipse help where they explain what it is. But I don't understand where to put the information to run my code? Is it in the feature.xml.
Lastly:
Is there an example how to create and use p2 touchPonts?
I implemented a custom action as shown here and I have a system that seems to work. I left out "touchpoint" extension as it's unnecessary in my case, but the rest is the same.
My action is executed during install phase of my feature (instructions.install) but maybe configure phase could work too. Collect phase did not work.
The action is executed during installation process, after the download was already performed. Ideally it would be before the download but it's not a big issue for me. Returning an error status from the action cancels the install. It leaves some downloaded files around but they do not get activated and are probably removed later by p2's garbage collector.
I also managed to do some more interesting things. My actions plugin has a dependency (optional and non-greedy) on my main plugin. So the install works like this:
Actions plugin is downloaded
Custom action is executed
The action detects whether my main plugin is already installed and if yes, it calls into it to retrieve licensing info. The main plugin has to expose an API for the action. The action also checks main plugin's version to detect whether the API is there or not.
The action now can decide whether to proceed or cancel the install. It can even interact with the user using Display#syncExec (this is what the code in checkTrust phase does so I think it's safe). If needed, the action could also detect whether the install is headless.
Some gotchas:
Action itself must be versioned. It's the version you declare in plugin.xml and p2.inf files and it's different from plugin's version. I just replace 1.0.0 with the same version my plugin has. This way the latest version of the action plugin is always downloaded before being executed. This is great because now any problem changes to licensing rules can be implemented in actions plugin.
Actions API changed between Eclipse 3.5 and 3.6. I will probably drop support for 3.5 as it's pretty old anyway.
Actions plugin should probably be signed. It's the case in my case. The system seems almost too powerful to me as just pointing Eclipse to an update site gets it to execute downloaded code.
I still need to test how this works with different versions of Eclipse and other IDEs. I saw a strange (non-blocking) error with 3.6. However the results are promising and it looks like the system might actually work.
Touchpoints are executed at installation time, which means that the resolution (validation) has already happened. I'm not sure they would help. What about creating an Installable Unit (IU) (or Eclipse Feature) that represents the license the user has installed. Then you would put a dependency from your product to that license.
For example, create an IU called com.mycompany.license (1.0.0). You would create another one called com.mycompany.license (2.0.0). When you installed a license, the appropriate IU would be added to the profile.
Now, when you go to install you product, the new version of the product would require license version 2.0.0. If this license was not installed, the resolution would fail.
Does this make sense? Do you think this would help?

Is it possible to change P4TICKET within P4Eclipse?

I installed Eclipse Juno recently and after it I installed the p4Eclipse 4.2 plugin from this repository:
http://www.perforce.com/downloads/http/p4-eclipse/install/4.2
Then I tried to create a new perforce connection.I entered the name of server and username and password. But I got an error message when clicking on next:
com.perforce.p4java.exception.ConfigException: java.io.FileNotFoundException: \p4tickets.txt (Access is denied)
Reading the P4Eclipse help I understood that because I didn't define the user environment variable P4TICKETS the P4Eclipse tried to define it by itself. On the help has mentioned that if the value is not explicitly is set it will be defined for windows as %USERPROFILE%\p4tickets.txt
and for all other platforms as
$HOME/.p4tickets
It seems that P4Eclipse has configured for other platforms and therefore it tried to find the file somewhere which it was not allowed. When I defined the User Environment variable P4TICKETS with the value %USERPROFILE%\p4tickets.txt it worked. The problem is that we have many clients and I don't want to define an environment variable for all of them. So I wonder if there is a set to configure P4Eclipse for Windows platform or define the P4TICKETS within eclipse and not with an environment variable!
Yes, I think you can go to the advanced configuration for the plugin and set P4TICKETS. In the release notes they describe this method for setting P4HOST:
470897 (Bug #042451)
Support for P4HOST variable. To set P4HOST variable,
either set the environment variable P4HOST (For example,
export P4HOST=123.456.789.0) or in the the preference page,
Preference>Team>Perforce>Advanced, set P4HOST properties,
(For example, name: P4HOST value: 123.456.789.0). Then
restart Eclipse to make it affect.
I'm not 100% sure that will work but you can give it a try.