[izpack-user] Finding an existing install
Grant Ingersoll
already exists, but it seems to be for Windows only, right? It also
has some obscure reference to "not forget to add the registry feature
into your installation." but I don't see where that registry feature
is specified. Also, what to do on *nix?
Thanks,
Grant
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Wilson Carl
doesn't seem to have anything unless you use an rpm to install the pacakge -
but then you wouldn't be using IzPack if you used an rpm.
I'd be interested in a solution as well. Doesn't seem to be anything apart
from inventing your own - or installing a dummy rpm as part of IzPack
install.
I've tried out the registry feature and found it rather messy. I fell back
on writing some java code (executeclass) to modify the registry depending
whether the user had admin rights (could modifiy HKLM) or not (fallback to
HKCU). Much more flexibility and easier than using the RegistryPanel under
Windows.
Regards
Carl
Thanks,
Grant
http://xircles.codehaus.org/manage_email
This email, including any attachment, is a confidential communication
intended solely for the use of the individual or entity to whom it is
addressed. It contains information which is private and may be proprietary
or covered by legal professional privilege. If you have received this email
in error, please notify the sender upon receipt, and immediately delete it
from your system.
Anything contained in this email that is not connected with the businesses
of this company is neither endorsed by nor is the liability of this company.
Whilst we have taken reasonable precautions to ensure that any attachment to
this email has been swept for viruses, we cannot accept liability for any
damage sustained as a result of software viruses, and would advise that you
carry out your own virus checks before opening any attachment.
Grant Ingersoll
will try to see if there is anything useful I can extract out of it at
some point and contribute back.
-Grant
--------------------------
Grant Ingersoll
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
Brett M. Bergquist
uses a XML registry file similar to Macrovision's InstallAnywhere
package and does not use the Windows registry. My requirements are that
I have to provide "packages" that are integrated into a core
installation and allow the packages to be installed and uninstalled
separately. So from a package installation, I need to be able to find
the core installation. It allows dependency checking during
installation and uninstallation. The other requirement that forced me
into developing IzRegistry was that I needed this to operate the same on
Windows, Solaris, and HPUX.
My package relies on finding a IzRegistry.xml file in a known location.
It can search for multiple locations to find it so it is flexible in
that manner. On Windows, I store it in "c:\program files\izpack" and on
Solaris I store it in "/opt/izpack". I created a couple of utilities
panels to support this. The first is a panel that will open the
registry and find specific entries based on a specification. From this,
it creates IzPack variables that can then be used by other panel such as
a CheckedHelloPanel. Another panel is used at the end of the
installation to update the registry file.
Here is a registry file with a few installations registered in it:
<izRegistry>
<installations>
<installation>
<info>
<appid>com.canoga.app.csem.core</appid>
<appversion>2.0 RC19</appversion>
<appname>CanogaView Smart Element Manager Core 2.0</appname>
<installdate>2008-04-16 10:27:57 EDT</installdate>
<installpath>C:\csem</installpath>
<uninstallpath>C:\csem\Uninstaller\uninstaller.jar</uninstallpath>
</info>
<packs>
<pack>Base</pack>
<pack>App</pack>
<pack>Win32</pack>
<pack>GlassFish</pack>
</packs>
</installation>
<installation>
<info>
<appid>com.canoga.app.csem.pkg.pcs</appid>
<appversion>1.0 RC19</appversion>
<appname>PCS Package 1.0</appname>
<installdate>2008-04-16 10:41:41 EDT</installdate>
<installpath>C:\csem/app/pkg/pcs</installpath>
<uninstallpath>C:\csem\app\pkg\pcs\Uninstaller\uninstaller.jar</uninstallpath>
</info>
<packs>
<pack>App</pack>
</packs>
<dependencies>
<dependency>
<appid>com.canoga.app.csem.core</appid>
<appversion>2.0 RC19</appversion>
</dependency>
</dependencies>
</installation>
<installation>
<info>
<appid>com.canoga.app.csem.pkg.pkg9145</appid>
<appversion>1.0 RC19</appversion>
<appname>9145 Device Package 1.0</appname>
<installdate>2008-04-16 10:44:09 EDT</installdate>
<installpath>C:\csem/app/pkg/pkg9145</installpath>
<uninstallpath>C:\csem\app\pkg\pkg9145\Uninstaller\uninstaller.jar</uninstallpath>
</info>
<packs>
<pack>App</pack>
</packs>
<dependencies>
<dependency>
<appid>com.canoga.app.csem.core</appid>
<appversion>2.0 RC19</appversion>
</dependency>
</dependencies>
</installation>
</installations>
</izRegistry>
From this, yhou can see that I have a package identified by
"com.cangoa.app.csem.pkg.pkg9145" that depends on
"com.canoga.app.csem.core" During instlalation, of the "pkg9145", it
will try to find the "core" package by opening the registry and looking
for the entry for "core". Also during uninstallation of "core", it
checks to make sure that no packages are installed that depend on it.
It warns the user if there are dependencies during uninstallation and
allows the user to quit.
Here is a sample specification file used by the "pkg9145" installation
that is used when the registry is read to extract the information about
the "core" package.
<?xml version="1.0" encoding="UTF-8"?>
<izRegistryReader>
<registry>
<registryFiles>
<os family="windows" />
<registryFile file="c:/program files/izpack/IzRegistry.xml"/>
<registryFile file="c:/temp/IzRegistry.xml"/>
</registryFiles>
<registryFiles>
<os family="unix" />
<registryFile file="/opt/izpack/IzRegistry.xml"/>
<registryFile file="/tmp/IzRegistry.xml"/>
</registryFiles>
</registry>
<installation>
<info>
<appid>com.canoga.app.csem.pkg.pkg9145</appid>
</info>
<dependencies>
<dependency>
<appid>com.canoga.app.csem.core</appid>
<appversion>2.0</appversion>
</dependency>
</dependencies>
</installation>
</izRegistryReader>
From this, you can see that on Windows, the code will look in 2 places
for the registry (one being a temporary location that I was using for
testing this feature), and on Unix it will look in a different place.
Also, you can see that the "pkg9145" declares a dependency on "core"
version 2.0 ore better.
I created an IzRegistryCheckPanel that checks for an previous
installation. It uses variables like:
<variables>
<variable name="IzRegistryCheckPanel.registryhello.appid"
value="com.canoga.app.csem.pkg.pkg9145"/>
<variable name="IzRegistryCheckPanel.registryhello.appversion"
value="1.0"/>
</variables>
This will check for a previous version of "pkg9145".
I created a IzRegistryPathPanel that checks for an installation of
another package. It uses variables like:
<variables>
<variable name="IzRegistryPathPanel.registrypathpanel.appid"
value="com.canoga.app.csem.core"/>
<variable
name="IzRegistryPathPanel.registrypathpanel.desiredVersion" value="2.0"/>
<variable
name="IzRegistryPathPanel.registrypathpanel.minVersion" value="2.0"/>
<variable
name="IzRegistryPathPanel.registrypathpanel.maxVersion" value="4.0"/>
<variable name="IzRegistryPathPanel.registrypathpanel.testFile"
value="Uninstaller/uninstaller.jar"/>
<variable name="IzRegistryPathPanel.registrypathpanel.path"
value="CSEM_INSTALL_PATH"/>
<variable
name="IzRegistryPathPanel.registrypathpanel.skipIfValid" value="yes"/>
</variables>
This will try to find the "core" package in the registry file with a
desired, min, and max versions acceptable. If there is one in the found
in the registry, it tests that the package is actually installed by
testing for a specific file. If the package is installed, the panel is
skipped by the "CSEM_INSTALL_PATH" variable is set to the installation
path of "core". If it is not installed, it may be because the registry
file is missing or was deleted, the panel will allow the user to find
the installation. This is very similar to finding a JDK from which I
based much of this panel on.
I am going to write up some documentation and propose this be added to
the IzPack distribution. There is no affects if it is not used and
provides a needed functionality, I think, for tracking installations
without using the Windows registry.
Wilson Carl
using IzPack.
When can it be included in IzPack - with the documentation?
Does the uninstall remove the XML registry entry/entries?
My general problem would be that, unless admin(root), installer wouldn't
have access to c:\Program Files (/opt). In an enterprise need to stop users
installing applications unless they have the required access permissions.
In fact I'd like to stop the IzPack installation if the user didn't have the
necessary access rights, so it would be good if the IzRegistry checked
whether it could write to the area and then aborted if not so that
'registration' is mandatory.
Alternatively, anyone got an IzAdmin/IzPowerUser/IzUser panel which could be
included in IzPack for Windows and something similar for *nix?
Carl
Jordi Giménez
I usually wrap the install and uninstall applications into an EXE using install4j in order to let the user do privilege elevation if needed. It also lets the installer work in Vista with UAC enabled. This solution is not so pretty as yours, but just works :)
--
Jordi Giménez
Área desarrollo
netquest
Tel: (+34) 93 2050063
e-mail: jgim...@netquest.es
Web: www.solucionesnetquest.com
Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es usted el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
O'Leary, Brian - 43
Jordi Giménez
launch4j lets you write an EXE wrapper for an external JAR file, instead of including all the content into the EXE file. This lets you prepare the file (for any existing uninstaller you already have) and change the uninstaller.jar later.
Hope this helps,
Jordi Giménez
Área desarrollo
netquest
Tel: (+34) 93 2050063
e-mail: jgim...@netquest.es
Web: www.solucionesnetquest.com
Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es usted el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
Brett M. Bergquist
At this moment, I don't have the time to add checks for user access to
the registry file. Right now, I just require "root" or "Administrator"
access during installation/uinstallation. The customers using our
packages are system adminstrators anyways so that is not a problem. I'm
not sure how that would work with a centralized registry file for the
system running as straight Java. I did see a "sudo" panel, so maybe
some ideas can be borrowed from there for the Unix side. The Windows
side sounds like some JNI code would need to be written.
Can you give a little better description on your requirements and use
case. This might stir some thought.
But a few more notes. As I mentioned, there is a registry reader panel
(IzRegistryReaderPanel) which needs to be right at the beginning of the
installation. This panel is hidden and uses the specification of where
to find the registry file. It is quite possible that you could have a
registry file per user if you wanted. I'm not sure that would help in
what you want to do, but I just wanted to point it out.
As for when can it be put in? Shortly I hope.
Wilson Carl
(primarily RHEL) and Windows (XP at the moment). The applications are
mainly related to software development, so we want a consistent environment
for all developers in a group. As an enterprise we don't like users
installing their own applications (licensing/legal issues, dependence on a
specific environment for development, etc.), but users may need to be able
to 'personalise' some of the setup so an IzPack 'configurer' can give users
some setup by choosing a few options or entering some info.
Typical 'applications' with IzPack include installing virtual machines on
either Linux or Windows hosts, configuring development environment UML tool,
installing plugins for Eclipse (linux and windows), configuring Eclipse for
versions of linux compiler, installing and configuring own applications,
etc. IzPack might just give a gui for installing an rpm and configuring it
for the user.
On Windows, the default is to use HKLM in the registry hive to register the
application for uninstall. That means that other applications can find it
to customise the development environment. Eclipse, for example, is normally
just expanded and plugins added. There are now Windows or Linux shortcuts.
If I wanted to find where a user had Eclipse installed I'd have to trawl
through every drive looking for it. Use the registry and I can find it
instantly and know how it's configured. If the user installs the software
then it would typically write to HKCU since the user doesn't have admin
rights. Java isn't very good at info about user rights. Our users wouldn't
have access to the internet to get Eclipse updates, so they only get what's
supplied to them.
I'd like to get the same type of functionality on Linux - but without using
rpms (yes, I do use those as well).
i.e. if root, then can install; if not root, then maybe a slightly different
install. Don't forget that HKCU changes with different users on Windows.
I'm only interested in knowing whether the current user has that tool, not
whether some other user of the machine has it installed. Not the ideal
universal solution, but I can live with it.
Looking forward to getting this added to IzPack.