[izpack-devel] Finding DefaultInstallationDirectoryforProgramsunder Windows

Tue Nov 28 16:59:31 CET 2006

Salut Fabrice

I have only tried to get it working with the more general "id="TargetPanel.dir"" (because our single target platform is windows). I tried to debug the TargetFactory-class but with no success. Then I searched for references to "TargetFactory.getDefaultInstallPath()" in Eclipse, but with no success. Therefore my conclusion that there must be something wrong.
But I have just found an other place that reads out the path form TargetPanel.dir: 
"PathInputPanel.loadDefaultInstallDir(..)" 

When debugging this, I found out, that the calls to parentFrame.getResource(..) for Windows and OSX are not inside a seperate try/catch and therefore break the processing of the "default" case. So we face two "problems":
1. Put those two calls into a try/catch as it is done for unix.
2. Cleanup the maybe redundant code between TagetFactory and PathInputPanel 

After working for some days with izpack, I have to mention, that silently gulping a general Exception is not a good practice. You should maybe use some logging api to log such exceptions - just for troubleshooting. It's ok for specific exceptions that are expected to be thrown. So if you plan to make some refactoring in the future, this may be a point to look at.

After all, I'll make a patch for "1." too and will provide it by the end of next week (I'm actually in military service and do not have a subversion client). But I am not the right guy to cleanup redundant code (this is also nothing of high priority I think).

Hope this clears up things.

Markus

________________________________

Von: izpack-devel-bounces at lists.berlios.de im Auftrag von miraodb
Gesendet: Di 28.11.2006 15:52
An: izpack-devel at lists.berlios.de
Betreff: Re: [izpack-devel] Finding DefaultInstallationDirectoryforProgramsunder Windows

Hi Guyz,

First of all sorry if i'm missing something but this discussion was hard to
follow for as i just came back from business trip...
Just one thing i don't get, are you guyz saying that doing :

<res src="TargetPathLin.txt" id="TargetPanel.dir.unix" />
<res src="TargetPathWin.txt" id="TargetPanel.dir.windows" />

with TargetPathLin.txt and TargetPathWin.txt files being at the root of your
installation doesn't work ?????

Coz it certainly works for me !
If that's really the case i'm really lost. I think that either something
went wrong in the latest merges or that i simply don't understand your
problem.

Lemme know what the deal is.
I do realise something from your previous mails,

$APPLICATIONS_DEFAULT_ROOT/Pulinco/MyProductXY

this is probably what is in your targetpathxxx.txt

problem could be that it's not parsed at all. Coz i have a hardcoded path
without blanks and it works fine (/apps or c:\apps)

Can you please send me your install.xml and confirm to me that if you use a
hardcoded path you still have the problem.

Cheers,
Fabrice
----- Original Message -----
From: "Markus Schlegel" <markus.schlegel at pulinco.com>
To: <izpack-devel at lists.berlios.de>
Sent: Tuesday, November 28, 2006 9:09 AM
Subject: Re: [izpack-devel] Finding Default
InstallationDirectoryforProgramsunder Windows

Hi Klaus

I think you missunderstood me a little bit. I do not claim about the code "
that it is badly designed" or something similar.
I program in Java since 1996, so I know the issues that where there in the
early stages of java (and some of them are still there :-(

To introduce myself:
- I work at Pulinco (www.pulinco.com) near Bern in Switzerland.
- I've studied Computer Sciences in the "Biel School of Engineering" from
1995 until 2000
- I work on a Product called "TopEase XBench" since 2001
- We used InstallAnywhere until now and are looking for an alternative
Installer since the Future of InstallAnywhere is very unclear (merger of
zerog with InstallShield, no support for Windows Vista yet)

Anyway, when you talk about Java1.1.8, I read in the docs, that I should
compile IzPack with a Target JDK of 1.4 .
But what is the minimum Java Version that izPack is meant to run on? Do I
have to compile for 1.2 (or even older) class compatibility? This is useful
information, if I have to send you patches as you know.

What would be interesting is, if someone (maybe I ?) has to cleanup the code
or the documentation for that "TargetFactory.getDefaultInstallPath" and/or
"TargetPanel.dir" which ?

Markus

________________________________

Von: izpack-devel-bounces at lists.berlios.de im Auftrag von Bartz, Klaus
Gesendet: Di 28.11.2006 12:27
An: izpack-devel at lists.berlios.de
Betreff: Re: [izpack-devel] Finding Default InstallationDirectory
forProgramsunder Windows

Hi Markus,
in the meantime I agree with you that IzPack should also find the right
default path
for applications on boxes with WindowsXP.
Last time we have discussed a little bit about the best way.
I am waiting for a WSH script from you until yet...But I agree with you,
that a simple environment
variable usage will be more robust, if the setting is common. I agree also,
that it should have
the old behavior as fallback. It should be no problem to check the existent
of the variable,
check the existent of the given path and so on.
You sad, you will create a patch for InstallerBase. Nice, I will wait now
for this.
You know patch as diff -u or as patch file.
To the other points of your email I can see only less because the code was
not written by me.
May be it is quite adventurous or the usage was very uncommon, but I think
the developer has
thougth something about it. You know, the code is a little bit older.  Do
you ever worked
with Java 1.1.8 on Windows 95?

As I sad, I am waiting for your patch (that with the environment variable)

Cheers

Klaus

-----Original Message-----
From: izpack-devel-bounces at lists.berlios.de
[mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Markus Schlegel
Sent: Tuesday, November 28, 2006 11:33 AM
To: izpack-devel at berlios.de
Subject: [izpack-devel] Finding Default InstallationDirectory for
Programsunder Windows

Hi
I already posted this issue on the User mailinglist.

The current official Release (3.9.0) does not read out the ProgramFiles
Folder from Windows. Instead it is read from a Properties file according to
the current Language on the system.

On International Installations of Windows with LanguagePack != English, this
fails always. Outside English-spoken countries, the international Version of
WindowsXP is the Quasi-Standard for Companywide Installations of Windows.

On such Systems, the Programfiles Folder is "Program Files" per default, no
matter which languagepack is installed (so you have a german system with
"C:\Program Files" as the Programs folder.

I made a patch now, which tries to read the Environmentvariable
"ProgramFiles" in the class "InstallerBase". If it fails or is not defined,
it falls back to the current implementation, which is sufficient for older
(pre W2K) systems (even if it is quite adventurous to derive the drive
letter from the user's home path). I took the Environmentvariable instead of
the Registry Key because reading out the registry Key requires further
classes and components.

What is left as a todo is the fact, that there is a Class called
"TargetFactory" with a Method "getDefaultInstallPath" which is in fact never
called. The Documentation states, that one can define a default
installationdirectory using the resource "TargetPanel.dir". Due to the Fact,
that "TargetFactory.getDefaultInstallPath" is never called, the setting of
TargetPath.dir has never an effect!

What should be the desired Functionality? Should the Value from
"TargetPanel.dir" overwrite the System default if defined? Is this feature
ever used (its very uncommon to do this when packaging the installer)?

Regards
Markus Schlegel

--------------------------------------------------------------------------------

> _______________________________________________
> izpack-devel mailing list
> izpack-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/izpack-devel
>

_______________________________________________
izpack-devel mailing list
izpack-devel at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/izpack-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 10948 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/izpack-devel/attachments/20061128/e283b994/attachment.bin 