Updating with documentation (I can't compile the docs on my side, so I hope i got everything formatted correctly).

Any help in how to write test cases for this would be appreciated. Thanks.

do you have minimal izpack's descriptor ( ie install.xml) include all necessary dependencies beside izpack compiler to demonstrate this feature? I can help using izpack-maven-plugin to create some sort integration test.

Attached is a quick and dirty sample project which just installs a single file README.txt, and issues some print statements during the various installer phases.

You should set he environment variable IZPACK_HOME to the your izpack installation. It's expected that the file lib/standalone-compiler will have the new BSF listeners in them. Then you can just run ant to build the sample installer.

Note the sample assumes you're going to use groovy as your scripting language. You could just as easily use Rhino, JRuby, Jython, or any other bsf supported language.

Of course, you'd have to include those jars in the installer.xml, and also alter the BSFActions.xml to name the correct language, and have valid code for that language.

PS: I've also tried this out with jython as well, just to be safe, and included the jython.jar file produced by running the jython installer, and selecting the standalone installation. Then my script entry in BSFActionsSpec.xml looks as follows:

<script language="jython"><![CDATA[
def beforePacks():
print "(jython) INSTALL_PATH=" , idata.getVariable("INSTALL_PATH")
return
]]></script>

So all seems to be well with the BSF integration as a whole. I don't seem to have done anything specific to groovy, although that's the only language I've been using with this.

On the feature: pluging scripts to handle events would be a nice addition.

On the implementation:

• Actions code is put in an XML document. I personaly would prefer to have them in a file of the target language (e.g., foo.rb for a Ruby file). Is there any way you could rework the solution to make that possible?
• Documentation of the change is great.
• The new files (e.g., BSFUninstallerListener.java) need to have our common license header.
• Please wipe the $Id$ marker in the DTD, as it is always a mess with version control and merges
• The addition of the BSF jar does not seem intrusive. Someone to confirm?

On the provided sample: it's a nice one, but it would be better if we had a smaller one for bundling with IzPack (that's many big jars to include!).

Verdict: I am in favor of merging this if other developers agree, and if the above points are adressed by an updated patch.

To your points:

1. I had thought about this, but the issue I ran into was two fold:
a. How do I ensure those external files gets packed in with the installer, and then how do I manage to find and run them
without having to have to unpack them into the installed application directory?
b. Same for the uninstaller

also, I personally prefer to include the scripts inline, though I am tpically not working with a large amount of packages, and my
scripts are typically for doing things like backing up files, cleaning up exploded webapps, etc....

At the worst, I would like to give the option to have the scripts inline or in an external resource.

2. Thanks

3. I can take the header from other files

4. No problem

5. I definately found that inclusion of the bsf and commons-logging jar did not add much to the installer size. The actual language
implementatiosn themselves (groovy, jython, etc...) are typically the space eaters.

Perhaps we can use a javascript example instead, as the rhino jar is only about 700K, compared to the ~2.3MB of groovy or ~1.9MB of jython.

If you could help out with item #1, at least in terms of some pointers, I can definately take care of the other solutions with no issues.

BSF Listener changes

I have added the appropriate headers to the java files and wiped out the $Id$ marker in the dtd. The diff file has been replaced to address this.

I will work on a beanshell oriented framework, as it has a very small footprint (275K).

Fixing some issues with Beanshell integration, allow us to specify different ways to check for method existence in different scripting languages.

Smaller sample which uses Beanshell for the scripting language, which makes it very lightweight in terms of the disk space used for the sample.

Adding in the ability to have a script as an external resource, or as embedded content.

I've added the ability to have a script be a resource name instead of just embedded content:

<script language="beanshell" src="actions.bsh" />

instead of

<script language="beanshell"><![CDATA[ ... ]]></script>

The caveat is that you have to include it as a resource in your installer.xml, and it will not
be parsed for variable subsitutions, whereas an embedded script would be:

<res id="actions.bsh" src="actions.bsh"/>

External scripts are still parsed for variable replacement though.

a correction to the previous comment, in that external resources WILL BE PARSED for variable subsitutions.

In BSFInstallerListener, there are a bunch of "params" maps that are never used...

Did you miss something, or can it be removed?

Reworked patch.

I have uploaded a reworked patch.

I would need your review Matthew, as well as a clarification on the "useless" params maps in BSFInstallerListener.

I will try to take a look at your changes, and the parameters within a day or two. I know the "variables" map is used to pass over to the uninstaller, since the uninstaller doesn't seem to have access to the "AutomatedInstallData" object, so had to add the variables as a seperate map in the uninstall action. (which also presents an interesting situation, in that the AutomatedInstallData object is not even packaged up with the uninstaller program.

Yes, I agree the "params" maps are useless. They may have been left over from something I was thinking about doing at one point, and can be safely removed.

I guess it woould be helpful if you outlined what you changed, as it will make it much easier for me to evaluate the changes.

Actually I made some really minor changes:

• documentation formating so that it is ok w.r.t. the reST format
• added generics on collections
• simplified a boolean expression or two
• ... and that should be it

Cheers

Sounds good to me.

It's in!

Thanks a lot Matthew for your work.

No problem. Nice to have it part of the standard izpack now instead of being a custom addition