[izpack-users] shortcutSpec.xml UTF-8 Byte Order MarkbreaksIzPackoperation

[Bartz, Klaus]

Hi Hans-Georg,
do you realy know a little bit more complex software which has
no bugs? I am not...
We need response from IzPack users if some think works not right.
Then we try to solve the problem. But we have all not much time
because nobody of us get's money for this job. Therefore some
user do not only acquaint a bug else they solve them and send
us a fix in form of a unified dif. It is take and give (in this
manner I have started with IzPack).
Buy a professional tool for about 2000 - 3000 EUR and look whether
the support is better as our or not. May be you have to pay
for support...
Your last email, where you sad that you would smash everything
reflected an other intention for me. To do not misunderstand
I have translated it with leo into my native language. All
possible translations are very destructive.
What do you mean what time I have used to find the reason why
a BOMed shortcutSpec.xml fails?


>-----Original Message-----
>From: izpack-users-bounces at lists.berlios.de
>[mailto:izpack-users-bounces at lists.berlios.de]On Behalf Of Hans-Georg
>Michna
>Sent: Wednesday, October 18, 2006 1:25 PM
>To: izpack-users at lists.berlios.de
>Subject: Re: [izpack-users] shortcutSpec.xml UTF-8 Byte Order
>MarkbreaksIzPackoperation
>
>
>On Tue, 17 Oct 2006 17:37:56 +0200, Bartz, Klaus wrote:
>
>>I have not written the shortcut part of IzPack, but if I look
>>into the sources it seems for me, that the parsing of the xml
>>file will be performed in the java part of the shortcut stuff 
>>(see ...panels.ShortcutPanel.readShortcutSpec).
>>OK, but why only a crash with the shortcutSpec.xml???
>>
>>Really good question. The shortcutSpec will be parsed also by
>>nanoxml, what else? In opposite to other specs this will be
>>directly substituted by the VariableSubstitutor. This uses a
>>InputStreamReader which uses StreamDecoder$CharsetSD. 
>>If a BOM is there, this will not consumed else read returns
>>65259 as first character. I do not know why and I do not know
>>whether this is a bug in the VM or not. I have the impression
>>that you like to write bug reports. Therefore retrace the bug
>>and write a report to sunsoft.
>
>Klaus,
>
>thanks for looking into this!
>
>I fear I'm not in a position to write a bug report to sunsoft,
>because I can't retrace or demo the bug for them. I would do it,
>if only I could. I'm not a Java developer and don't even have a
>Java compiler or debugger ready. (This may change soon, but not
>yet.)
>
>In fact I don't like to write bug reports. I strongly prefer
>bug-free software. But I do write them, if I have to. If I find
>a bug that will affect many other users, I will write a bug
>report, even if I already know a workaround. A little bit of
>altruism here, in return for the altruism of the developers, who
>do all the major work. I hope, of course, that the developers
>appreciate bug reports.
>
>By the way, currently I'm stumped by the other apparent bug,
>concerning <executable ...> (see other thread). If I cannot
>resolve that, my choices are very limited. Going back to 3.8.1
>is nearly out of the question, so I'd have to go to another
>product altogether, probably install4j. I hope I'm only making a
>mistake here and someone can point it out, or perhaps it's
>another one of those documentation mismatches. Do you have any
>idea about that one? Should go in the other thread, but since
>you're reading this one, I thought I might as well ask.
>
>Hans-Georg
>
>-- 
>No mail, please.
>
>_______________________________________________
>izpack-users mailing list
>izpack-users at lists.berlios.de
>https://lists.berlios.de/mailman/listinfo/izpack-users
>