[izpack-users] Specifying Required Packs and OSs

[Klaus Bartz]

Hi Hal,
Am 02.01.2006, 03:44 Uhr, schrieb Hal Vaughan <hal at thresholddigital.com>:

> On Sunday 01 January 2006 04:52 pm, Klaus Bartz wrote:
>> Hi Hal,
>>
>> Am 31.12.2005, 18:42 Uhr, schrieb Hal Vaughan  
>> <hal at thresholddigital.com>:
>> > Have you had any problem with the packs for one OS being installed on  
>> the
>> > other OS?
>>
>> No.
>>
>> > I'm testing on Linux and WinXp.  I found if I specified one pack
>> > as "windows" and the other as "linux" the test install on Linux gets
>> > only the
>> > "linux" pack, but the test install on Windows gets both packs.  (And  
>> I'm
>> > using the latest version of IzPack!)
>>
>> "linux" is not a valid name for the OS attribute of all elements like  
>> pack,
>> file, fileset etc.
>> The attribute OS is old and will be present for compatibility. There  
>> only
>> the
>> three values "windows" "unix" and "mac" are valid. The element OS is  
>> newer
>> and
>> you can specify the os in more detail. In addition to the family
>> ("windows" "unix" and "mac") you can specify the OS name like "Windows  
>> XP".
>> The name will be given by the VM using System.getProperty("os.name"). I
>> doubt
>> that "linux" will be a valid os.name property of a VM.
>
> Okay.  This is VERY helpful.  I got the attributes and elements mixed up.
> I'll take that into account.
>

This was a digest related to your problem of the IzPack API and a little
comment why we use it in this manner.

> ...
>> Using the OS attribute "linux" at the element <file> does also NOT work.
>> It is the same behavior. I had offered that I can look into your pack
>> declaration. If it is not an option for you, also OK. I think, my real
>> pack declarations will only confuse you more. Therefore an example of an
>> install.xml only for seeing how to declare OS dependency of packs:
>
> Actually, I will probably post my install file.  Basically, I was hoping
> creating the install would be a one day thing.

If you are firm with the design of IzPack you need less than a half hour
for a simple installation. For complex installations the most problem will
be to find the right pice of IzPacks features and configure in the right  
way.

> I spent from noon one day
> until 5 am the next reviewing packages and trying to learn enough to  
> make a
> choice.  The next day I was focused on using IzPack, and had to either  
> finish
> it and set it aside.  Things were not working (I suspect there are some  
> bugs
> in the UserInput Panel and some serious bugs in the Search subclass, or
> possibly the PathInput Panel, since it would not list default  
> directories in
> the UserInput or JDKPath Panels in some cases).

Be carefully with words like bug. For me a bug exists if there is a  
diffenrence
between the documented and the real behavior. There is not ever a bug, if  
a program
do not the things I think. In other words: IzPack is a "simple" program  
written
in classic style without any "intelligence". We have never said, that our  
program
will be able to thought-reading. See my answer to your first email to this  
list.
Implicit I have warned you. You can have an installer developing kit for  
free, but
not a ready installation.

This mailing list was intended to help users
of our product if they have problems. May be some bugs will be detected  
during
problem resolving. But if some one said on every problem that there is a  
bug
in our product makes me not happy.
In special the JDKPathPanel docu said:
"If JAVA_HOME points to the VM which is placed in the JDK, the directory  
will be used as default (JAVA_HOME/..)"
and
"Additional it is possible to make a version control. If one or both  
variables

JDKPathPanel.minVersion
JDKPathPanel.maxVersion

are defined, only a JDK will be accepted which has a version in the range  
of it. The detection is a little bit pragmatically, therefor it is  
possible, that the detection can fail at some VMs."

I really do not know what I should say more...
May be you would have a full scan of all HDs, but this will be not generic.
There are not so much people which are happy if the installer needs more  
than
fifteen minutes to resolve a default path. The common limit will be one,  
may
be five seconds, but not more.
One of the big benefit of IzPack is, that you have all common sources and
you can adapt it to your own needs. Do it. A scan algorithm will be need
a half or two hours, I think.

> It was basically getting to
> the point where I had tried everything that seemed logical and it was not
> working.  So I had a few hours left and was trying everything I could.  I
> think, at this point, it is a mess.
>
> However, the next project I had to do was supposed to take up to 2 weeks  
> and
> it worked out in a day, so now I have time to come back to this issue.   
> I'll
> take what you have said into account and see if it helps.  The file  
> (below)
> is also a help for me.
>
> As to my original question, I am concerned because I need to include
> OpenOffice, which is a lot of data to download, so I don't want an  
> internet
> install to download both Linux and Windows versions.

You know, "windows" is in IzPack a symbolic name for a OS family,
"Linux" may be a OS name, but I assume most undefined.

> To handle this, I think
> I'm going to just create 2 installers, one each for Linux and Windows.
>

No this is not for what we have created IzPack. One installer for all
supported OS.
You can make a net installation with separated jar files for each pack.
If you use the OS declaration right, only the needed jars should be  
downloaded.
If not (I use the net feature not), that will be really a bug.
But I will really wonder if it do not work. The code  
Unpacker.getPackAsStream
is very clear.

Cheers

Klaus
-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/