IzPack

Submission of BSF Scripting Feature

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 4.2.0
  • Fix Version/s: 4.3.0
  • Component/s: Installer
  • Labels:
    None
  • Patch Submitted:
    Yes
  • Number of attachments :
    5

Description

This feature enables the use of any BSF 2.4 supported language as a way to script install and uninstall events. Attached is the SVN patch file and bsf.jar file (version 2.4.0 of bsf) which should be placed in the "lib" directory.

The patch file contains the new source code, as well as the build.xml modifications necessary to build the new listeners.

I'm still trying to figure out how the documentation is generated, so i can add that. Any help would be appreciated.

Attachments

  2. File
    bsf-jp.diff
    18/Jan/09 3:26 PM
    38 kB
    Julien Ponge
  3. File
    bsf-listener.diff
    16/Jan/09 12:09 PM
    35 kB
    Matthew Inger
  4. GZip Archive
    sample.tar.gz
    08/Jan/09 12:00 PM
    3.08 MB
    Matthew Inger
  5. GZip Archive
    sample2.tar.gz
    16/Jan/09 12:09 PM
    414 kB
    Matthew Inger

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Matthew Inger added a comment -

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

Show
Matthew Inger added a comment - Updating with documentation (I can't compile the docs on my side, so I hope i got everything formatted correctly).
Hide
Permalink
Matthew Inger added a comment -

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

Show
Matthew Inger added a comment - Any help in how to write test cases for this would be appreciated. Thanks.
Hide
Permalink
Dan Tran added a comment -

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.

Show
Dan Tran added a comment - 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.
Hide
Permalink
Matthew Inger added a comment -

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.

Show
Matthew Inger added a comment - 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.
Hide
Permalink
Matthew Inger added a comment -

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.

Show
Matthew Inger added a comment - 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.
Hide
Permalink
Matthew Inger added a comment -

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.

Show
Matthew Inger added a comment - 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.
Hide
Permalink
Julien Ponge added a comment -

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.

Show
Julien Ponge added a comment - 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.
Hide
Permalink
Matthew Inger added a comment -

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.

Show
Matthew Inger added a comment - 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.
Hide
Permalink
Matthew Inger added a comment -

BSF Listener changes

Show
Matthew Inger added a comment - BSF Listener changes
Hide
Permalink
Matthew Inger added a comment -

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).

Show
Matthew Inger added a comment - 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).
Hide
Permalink
Matthew Inger added a comment -

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

Show
Matthew Inger added a comment - Fixing some issues with Beanshell integration, allow us to specify different ways to check for method existence in different scripting languages.
Hide
Permalink
Matthew Inger added a comment -

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

Show
Matthew Inger added a comment - Smaller sample which uses Beanshell for the scripting language, which makes it very lightweight in terms of the disk space used for the sample.
Hide
Permalink
Matthew Inger added a comment -

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

Show
Matthew Inger added a comment - Adding in the ability to have a script as an external resource, or as embedded content.
Hide
Permalink
Matthew Inger added a comment -

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.

Show
Matthew Inger added a comment - 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.
Hide
Permalink
Matthew Inger added a comment -

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

Show
Matthew Inger added a comment - a correction to the previous comment, in that external resources WILL BE PARSED for variable subsitutions.
Hide
Permalink
Julien Ponge added a comment -

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

Did you miss something, or can it be removed?

Show
Julien Ponge added a comment - In BSFInstallerListener, there are a bunch of "params" maps that are never used... Did you miss something, or can it be removed?
Hide
Permalink
Julien Ponge added a comment -

Reworked patch.

Show
Julien Ponge added a comment - Reworked patch.
Hide
Permalink
Julien Ponge added a comment -

I have uploaded a reworked patch.

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

Show
Julien Ponge added a comment - I have uploaded a reworked patch. I would need your review Matthew, as well as a clarification on the "useless" params maps in BSFInstallerListener.
Hide
Permalink
Matthew Inger added a comment -

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.

Show
Matthew Inger added a comment - 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.
Hide
Permalink
Matthew Inger added a comment -

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.

Show
Matthew Inger added a comment - 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.
Hide
Permalink
Julien Ponge added a comment -

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

Show
Julien Ponge added a comment - 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
Hide
Permalink
Matthew Inger added a comment -

Sounds good to me.

Show
Matthew Inger added a comment - Sounds good to me.
Hide
Permalink
Julien Ponge added a comment -

It's in!

Thanks a lot Matthew for your work.

Show
Julien Ponge added a comment - It's in! Thanks a lot Matthew for your work.
Hide
Permalink
Matthew Inger added a comment -

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

Show
Matthew Inger added a comment - No problem. Nice to have it part of the standard izpack now instead of being a custom addition

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.