[izpack-dev] Problems with <jar> element in the installer configuration; also with actions within the panels

[Coquelicot]

Hi,

I'm a (happy) user of IzPack for a long time and I didn't have any
problems with it until recently, when I switched from version 4.x to
5.0.0-beta8 (because of its nice integration with Maven/Ivy). In my
case I am using Apache Ivy and Ant (not Maven) to construct the
installer using standard Ant task (class
com.izforge.izpack.ant.IzPackTask).

As I use some custom panels in my installer I had to update the code a
bit to fit the new Java package schema (that was quite easy) but what
I am stuck at now is adding contents of a JAR file to the installer
(using the <jar src="..."/> element). For some reason, I can't make it
work - installer just refuses to add it, even though the path to the
JAR file (as specified in <jar src="/path/to/jar/file.jar" />) is
correct (if it's incorrect, the installer building fails - which is
correct I suppose).

Did the handling of <jar .../> elements changed in 5.0.0-beta8? before
it was just unpacking the contents and merging them into the installer
JAR. I was using it to first: provide the classes for my panels and
the resources that could be accessed from them.

=====

Another thing that fails is attempt to include an action for
UserInputPanel like that:

...
<panel classname="UserInputPanel" id="basic.system.config">
<actions>
<action stage="preconstruct"

classname="some.package.actions.SetExtraVariablesPanelAction"/>
</actions>
</panel>
...

The error I'm getting is following:

[izpack] Copying the skeleton installer
[izpack] Exception in thread "Thread-1"
java.io.NotSerializableException:
com.izforge.izpack.api.data.binding.Action
[izpack] at
com.izforge.izpack.ant.IzpackAntRunnable.run(IzpackAntRunnable.java:76)
[izpack] at java.lang.Thread.run(Thread.java:636)
[izpack] Caused by: java.io.NotSerializableException:
com.izforge.izpack.api.data.binding.Action
[izpack] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1180)
[izpack] at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
[izpack] at java.util.ArrayList.writeObject(ArrayList.java:673)
[izpack] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[izpack] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[izpack] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[izpack] at java.lang.reflect.Method.invoke(Method.java:616)
[izpack] at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:962)
[izpack] at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1480)
[izpack] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
[izpack] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
[izpack] at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
[izpack] at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
[izpack] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
[izpack] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
[izpack] at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
[izpack] at java.util.ArrayList.writeObject(ArrayList.java:673)
[izpack] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[izpack] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[izpack] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[izpack] at java.lang.reflect.Method.invoke(Method.java:616)
[izpack] at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:962)
[izpack] at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1480)
[izpack] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
[izpack] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
[izpack] at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1528)
[izpack] at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1493)
[izpack] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1416)
[izpack] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
[izpack] at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:346)
[izpack] at
com.izforge.izpack.compiler.packager.impl.Packager.writeInstallerObject(Packager.java:170)
[izpack] at
com.izforge.izpack.compiler.packager.impl.PackagerBase.writeInstaller(PackagerBase.java:353)
[izpack] at
com.izforge.izpack.compiler.packager.impl.Packager.createInstaller(Packager.java:123)
[izpack] at
com.izforge.izpack.compiler.Compiler.createInstaller(Compiler.java:132)
[izpack] at
com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig.java:256)
[izpack] at
com.izforge.izpack.ant.IzpackAntRunnable.run(IzpackAntRunnable.java:72)
[izpack] ... 1 more

I have tried to add 'implements Serializable' to my panel action class
that I try to add but it doesn't help.

Any help would be appreciated! big thanks,

Lukasz

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

http://xircles.codehaus.org/manage_email

[Coquelicot]

Hi again,

I did some more checks and it seems that <jar> element works but only
with attribute 'stage="both"'; the JARs are not merged into the
installer JAR if 'stage="install"'.

Lukasz

[Timothy Fridey]

Having provided a couple of patches to Izpack I must say I was amazed that a project of this size has so little regression testing. This is a clear example of where they would have come in handy.  I have also noticed that maybe bugs reported are due to regression problems. Can I just make a suggestion that future bug fixes (especially those that deal with core config processing ) are only accepted with accompanying JUnit tests, that:
1. Test for the error

2. Test for the correct outcome.

I know people like to say JUnit's just take up development time, but I believe they are an investment that reduces development time and the shift toward Test Driven Development supports this view. Many complex projects such as Maven itself will not accept changes without unit tests. I'm not suggesting someone go back and write JUnit for everything as that adds little value, but I would suggest anything new should have a corresponding unit test. In the long run time saved on regression issues will be enormous. 

Anyway that's just my two cents, take it or leave it.

Tim

---

From: Coquelicot <coquel...@gmail.com>
To: d...@izpack.codehaus.org
Sent: Tuesday, 26 July 2011 5:11 PM
Subject: [izpack-dev] Re: Problems with <jar> element in the installer configuration; also with actions within the panels

[Julien Ponge]

We love tests, really. I cannot develop a project without a solid tests suite anymore.

That being said you should understand that IzPack was created in 2001, a time when Ant was fresh and JUnit was not widespread if existing.

The refactoring of v5 is a typical showcase of reachitecting a project, removing circular dependencies, introducing tests there and there… but clearly there could be more of it, so if you have time for this then you are more than welcome ;-) 

-- 
Julien Ponge

http://julien.ponge.info/

[Julien Ponge]

I did some more checks and it seems that <jar> element works but only
with attribute 'stage="both"'; the JARs are not merged into the
installer JAR if 'stage="install"'.

I'll take care of this one personally: https://jira.codehaus.org/browse/IZPACK-683