[izpack-user] accessing command line args from installer

[Steve Poole]

I don't see this described in the docs. Is there a way to access command
line arguments from within an installer?

My specific case is that I will be launching an installer from another
application. That application will know the value of a couple of
directories. I would like the launched installer to use those values by
default, rather than forcing the user to make a selection.

Is this possible? Thanks!

Steve

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[René Krell]

Hi Steve,

you can always use the "SYSTEM_" prefix to access system properties in common,
either default Java system properties or those given on the command line. But
this might not fulfill your requirement without building a workaround into
your installer and I guess you've already seen this.

The feature by your means are unattended installations.
With the current IzPack releases you can only use the automated installation
xml file (for example auto-install.xml), created once by the FinishPanel
(http://izpack.org/documentation/panels.html#finishpanel) and modify it by
your needs. You can then use this Xml file as input to your installer:
java -jar jarfile auto-install.xml
For generating this template you might start at least one sample installation.

With IzPack 5.0 there will come a second feature:
Add -console-auto option to read options from system properties
(http://jira.codehaus.org/browse/IZPACK-405)
This way you will be able to initialize IzPack variables over the command
line. I've tested this with giving the main installation path to the
installer:
java -DINSTALL_PATH=/opt -jar install.jar -options-system
but haven't tested it with dynamic variables used in various user input
panels. You will have to wait for this feature until IzPack 5.0 is released
(or if there will be a backport to some intermediate release).

René

[Michael Hagedorn]

Steve,

I used environment variables to pass custom values.

Michael

[Steve Poole]

I just wanted to close the loop on this. Thanks to René Krell for the
suggestion regarding system properties, and to Michael Hagedorn for the
suggestion regarding environment variables.

Both of those have problems in certain cases for me. The system properties
are a problem when the installer is configured to run with privileges (on
the Mac, anyhow). In that case, the properties defined on the command line
in the original Java invocation are not propagated to the process when it is
relaunched.

The environment variables have a similar problem, in that when an
application is run via sudo on many Unixy systems the propagated environment
is usually a predefined or whitelisted subset of the current environment.
That makes a generalized solution pretty tough.

For now I'm using the Java preferences store, but that also has issues
related to current user and privileged execution. I will probably end up
just writing values to a file from one app and reading them from custom code
in my installer app.

In my opinion the privileged relaunch losing the properties is a bug, though
I'm not sure off the top of my head whether it is fixable. I don't know if
it's also true on Windows.

Thanks again!

Steve

[René Krell]

Hi Steve,

can you just give a short example, how the application launches the IzPack
installer or how to you intend the command line has to be? Is it something
like this:
java -DINSTALL_PATH=/some/path -jar install.jar
?
I will look for it whether this will be solved at least in the current
development towards IzPack 5.

René

[Dmitry Katsubo]

Hi Steve!

I think windows can elevate privileges if you make exe-wrapper (see example of how we use launch4j-plugin) for your application and the JVM will be started with already raised privileges. I hope the same will also work for Linux. I also wonder why you loose environment in Linux, as you start installer with e.g. sudo installer.sh, while installer.sh should setup the environment. Having installer dependant on some user settings sounds like not a good idea. Or you need to access variables like ORACLE_HOME? Interesting, which Unixes have sudo so secured that they clean everything...

With best regards.

Dmitry

[Steve Poole]

Hi Dmitry. I am, in fact, running these tools from install4j in certain cases, and I think you’re right that i4j will launch with the current privileges. I’m having a little more trouble with the i4j and the Mac environment, and cross-platform differences in this area are just generally awkward.

I need to these utilities to work on a bunch of platforms, when launched from another app or when launched by the user directly, for operations that may or may not require admin privileges, and for unsophisticated users. It’s tricky!

Environment variables aren’t my preference for this, so I didn’t look too extensively into all the places where they wouldn’t work. The Mac OS X sudo uses a whitelist, as do at least a couple of Linux distros I researched.

Steve

On 4/9/10 8:05 AM, "Dmitry Katsubo" <dmitry....@gmail.com> wrote:

Hi Steve!

I think windows can elevate privileges if you make exe-wrapper (see example <http://ws1.grid.sara.nl:21501/artifactory/libs-snapshots-local/org/erasmusmc/data-mining/peregrine/peregrine-installer/0.4-SNAPSHOT/peregrine-installer-0.4-SNAPSHOT.pom>  of how we use launch4j-plugin) for your application and the JVM will be started with already raised privileges. I hope the same will also work for Linux. I also wonder why you loose environment in Linux, as you start installer with e.g. sudo installer.sh, while installer.sh should setup the environment. Having installer dependant on some user settings sounds like not a good idea. Or you need to access variables like ORACLE_HOME? Interesting, which Unixes have sudo so secured that they clean everything...