Here are the steps for each platform:

Windows:

1. Open up XRap, and select the root of your XULRunner application directory, and click next.
2. Select the type of License you would like to attach to your application from the drop-down list of available licenses.  You can optionally select your own license, or no license at all. Once you have selected your license option, click next
3. You must now select the type of installer you would like your end-user to have.
   • Automatic Installer – Will automatically install your application on to the end-user computer, with no wizard.
   • Wizard Installer – Will start the Windows Installer wizard, showing your license agreement on a single page, and giving the option for the end-user to install your application to a custom path.
   • Minimal Wizard Installer – Will start the Windows Installer wizard, using only one page, which shows the license agreement, then installs your application to the default directory.
4. Once your have selected the type of installer you want, click next, and XRap will package your application
5. When successfully completed, XRap will go to the last page where you can open the directory of where your new msi will be located, and your can close XRap.

Linux

1. Open up XRap, and select the root of your XULRunner application directory, and click next.
2. Select the type of License you would like to attach to your application from the drop-down list of available licenses.  You can optionally select your own license, or no license at all. Once you have selected your license option, click next
3. You can optionally select to create a zip file of your application for distribution on Windows.  Click next to continue.
4. XRap will now package your application into a tar.bz2, and optionally a zip file if selected.
5. When successfully completed, XRap will go to the last page where you can open the directory of where your tar.bz2 file will be located, and your can close XRap.

Mac

1. Open up XRap, and select where your XULRunner application (with the .app extension) is located, and click next.
2. Select the type of License you would like to attach to your application from the drop-down list of available licenses.  You can optionally select your own license, or no license at all. Once you have selected your license option, click next
3. XRap will now package your application into a dmg.
4. When successfully completed, XRap will go to the last page where you can open the directory of where your dmg file will be located, and your can close XRap.

I hope to release an updated version where you can create simple packages for different platforms.  Similar to how you can create a zip file on Linux for distribution on Windows.  My current plans are:

Windows:

1. Create a zip file for release on Linux
2. Create a zip file for release on Mac, I will have to refactor the directory structure so that it aligns with the Mac model

Linux

1. Create a zip file for release on Mac, I will have to refactor the directory structure so that it aligns with the Mac model

Mac

1. Create a zip file for release on both Windows and Linux

I plan to work on it over the summer, and hope to be compeleted within the next couple months.  Please post any new bugs found on xrap.sourceforge.net.

Enjoy!

XRap Version 1.0

• Added a license page
• Added a page to validate that you are packaging a XULRunner application
• The wizard automatically goes to the last page once pacakaging is complete
• If there are any errors, they will show on the last page
• Linux release now creates a tar.bz2 file, with an installation script attached to it
• Linux release can create an additional zip package for release on Windows
• Windows release now has a description for each of the MSI Installers
  • The MSI Installers make the end-user view the attached license before they can install the software

At first I added the license page so that the MSI installer can make use of it, but it only makes sense that all users should be able to attach a license to their software.  Here’s another list of the licenses I chose to include:

• Common Public License 1.0 (CPL)
• GNU General Public License (GPL)
• GNU General Public License version 3.0 (GPLv3)
• GNU Lesser General Public License (LGPL)
• GNU Lesser General Public License version 3.0
• Common Development and Distribution License
• Mozilla Public License version 1.1

Should these licenses be too restricting (or not enough) the user can attach their own license, or none at all.

The decision to ditch Autotools in my Linux packaging was an easy one.  It was too bloated.  Added all kinds of unnecessary files to a release.  And it just didn’t make any sense.  After having a look at a paper by Mark Finkle, and using his release of the XULExplorer  as a template, I decided to just write a script which will just “tar” up the application.  Yes, it still check to make sure you are packaging a XULRunner app.  To make it slightly appealing, I added a script to each package, which when run will run the ‘–install -app’ command for XULRunner.  It will take the app and copy it into the //usr/lib/vendor_name/application_name/, and then create a bash script which calls the application, and put it into your /usr/bin directory, so that you can call the new application from a single command.  I don’t know how well received it will be, but I haven’t heard any feedback about it yet.

Out of everything I have learned for this release, the one that hurt my brain the most was how complicated it is to make a zip file on Linux.  The reason I wanted to make a zip file was so that users of Linux can have the ability to release their product easily for use on the Windows platform.  Unfortunately, I tried using Mono to compile my WiX (which is built on the .NET platform) files,  it could get as far as using light which is the linker stage (candle works, to compile).  The reason it fails is because you need the msi.dll library, and unfortunately that is only for Windows.  So the next logical move was to zip the application, and let the end-user run it from the unzipped directory.  After a lot of troubleshooting, creating the zip file wasn’t too complicated after all, my scripts were just wrong.  I must admit, that is one more thing that I have learned in this process, how to write shell scripts.

Overall, everything is really looking solid, I have fixed the Mac release, so that it can correctly read .app XUL files, can create a DMG out of them,  Linux can create a tar.bz2 with ease, and Windows can spit out an msi with no problem.  Now just testing, and working out the bugs that people find.

Version 0.9 can be found @ xrap.sourceforge.net

Enjoy, and GIVE ME FEEDBACK!!! I want to know about bugs/features/anything else that is needed

After talking to some guys in the #xulrunner channel on IRC, I foundout that my Mac applications were setup all wrong.  At first I was like, why would they do that?  But after getting it to work, I figured that it was pure genius!  First of all, I was simply copying over my XUL app directly from my Linux box to a Mac, and then running it from Terminal:

//Library/Frameworks/XUL.framework/xulrunner-bin /path/to/app/application.ini

It worked, so I went with it.  To install an app, you just add ‘–install-app’ to the end of ‘xulrunner-bin’, and it will stick it into the Applications folder.  For some reason or another, Once it was installed, I could run it.  But when I tried that same procedure on other machine, it didn’t work.   Hmm.  After some conversations, and reading, notice and article on MDC on Deploying XULRunner 1.8, and there was my answer.
Basically XULRunner on Mac has a different file structure, which is as follows:

MyApp.app/

• Contents/ 
  • Info.plist
  • Frameworks/ 
    • XUL.framework/ 
      • …all the XULRunner files
• Resources/
  • application.ini
  • icon.icns
  • components/
    • everything in your normal component directory
  • chrome/
    •  everything in your normal chrome directory
  • all your additional files and folders
• MacOS/
  • xulrunner (the file copied from the ‘xulrunner’ stub, not the xulrunner-bin)

MyApp.app is actually a directory, with a ‘.app’ extension on it.  All it did was create a directory, put all my files in the correct structure, add the ‘Info.plist’ file, and rename the directory with the ‘.app’ extension.  The Info.plist file was probably the most complicated to recreate.  The example from MDC is not very helpful, especially if you don’t know what your doing, and have to write it by hand.  However there is a “Property List Editor” application on Mac, which will help you create the file.

Property List Editor

These are the properties which must be in your Info.plist file, for your XULRunner application to work.  Key fields which are important are:

The actually XML file looks like this:

<?xml version=“1.0″ encoding=“UTF-8″?>

<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=“1.0″>
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>XRap</string>
<key>CFBundleGetInfoString</key>
<string>XRap 0.9</string>
<key>CFBundleIconFile</key>
<string>xulwizard-window</string>
<key>CFBundleIdentifier</key>
<string>net.sourceforge.xrap</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>XRap</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleShortVersionString</key>
<string>0.9</string>
<key>CFBundleSignature</key>
<string>Mac</string>
<key>CFBundleVersion</key>
<string>0.9</string>
<key>NSAppleScriptEnabled</key>
<true/>
</dict>
</plist>

Its best to do all your work in your application directory, before adding the .app extension, because then it is treated like a file, and you will be unable to enter the directory, unless you remove the extension.

In refactoring XRap, I was still able to access the directory even though it was a .app.  Using nsIFile to add files (the License), and read the application.ini, with no problem.  In packaging, using pkg-dmg script, I had to create a staging area (temporary directory) and copy the .app into it, because the script only accepts directories to be imaged.  If I tried to image the .app, it would image it as a directory and add .dmg to the end, defeating the purpose.

Well now I am proud to say that Mac packaging is complete.  You can now package an application as an dmg image.  When a user downloads the image, all they need to do is mount it, and run your app.

I want to eat an apple now.

Default XUL Icon

I used GIMP to create the box.  Which ended up just being a lot of trial and error with the shading on the sides of the box.  I’m not too sure if the perspective is correct, but it turned out ok for someone that knows very little about graphic design.  

Final XRap icon

To applying the icon to XRap is actually quite easy.  Simply put the icon into:

(application name)/chrome/icons/default/

then for Windows, you will need an icon with the .ico extension, while on Linux you will need an icon with the .xpm extension.  The name of the icon will be the id of your application, which will be located in the <window> element of your xul code.  I believe there is another way to apply your icon to your application, through the branding content package, which must be defined in your manifest.

The step for creating a package is the same as create one for Linux and Windows, one the first screen open the directory to where your application is stored, click the ‘Next’ button, and XRap will create a script to install your application into the Applications folder, and then create a dmg of the application folder. Done!  

Windows packaging is just about finalized, and running perfectly.  Linux on the other hand might need some last minute refactoring.  After working on the Mac, and talking to some people on IRC, I realized that ‘xulrunner-bin –install-app’ is an awesome script, and that there should be one for Linux.  There is, only it is ‘xulrunner –install-app‘.  So now I might scrap all of the Autotools work (which will also remove the prerequisite of the developer needing autotools installed), and just tarball the application and create an install script for it, which will put it into ‘/usr/lib/’ for all Linux distros.  One of the benefits of dumping Autotools, is that I can now write an install script, and zip it on Windows, the same method can also apply for Mac, since it is not possible to create a dmg without a Mac, I can write an install script and zip.  This will tackle one of the requests, that XRap be able to package for any platform, no matter what you are working on.  It should definatly be done by my 0.9 release.  

I have got a ton of ideas from my professor on little ideas/features to make XRap a better product.  Here’s a list of things which I have compiled which I expect to be completed for the next release:

• Use a ‘Throbber’ for the Packaging status screen, so that the use knows the application is working.
• On the last page create a link to the destination of the output file.
• On the second page allow the user to import/apply a license into their application, by giving them a list of available licenses to choose from, or apply their own.
• For the Windows version of XRap, give a description of each Installer, and change the dropdown list of Installers to a list of radio buttons
• Automatically go from the ‘Packaging Status’ page to the ‘Completion page’ when packaging is complete
• Create an installation log generator
• Logo (for final release)

Tinkering…

/Library/Frameworks/XUL.framework/

This will make available ‘xulrunner-bin’, which will be needed to run the XUL app.  I noticed (and liked) that the XULRunner runtime is installed in a default location similar to Linux and unlike Windows, where it is just where you put it, and you have to set a bunch of environment variable to point to it.  To run a XUL app, is almost just as easy, there are two ways:

Install the application:
 /Library/Frameworks/XUL.framework/xulrunner-bin –install-app /absolute/path/to/app.zip

Run the application (without install):
  /Library/Frameworks/XUL.framework/xulrunner-bin /absolute/path/to/application.ini

If you choose to install the application, it can be a XUL app packaged in a zip file or a folder of a XUL app, but it will conviniently put your installation into the:

/Applications/<vendor>/<appName>/

You can then run the app.  If your developing, it may be a better idea to simply run the application, however there is a warning on MDC that the menu bar and dock icon may be missing.  From experience, on my first run, the command executed, and I got nothing, and the bash prompt appeared, so I ran it again and I received a message that the app was already running.  No window opened or anything, so I just closed the Terminal, refactored my code (I think there were some errors in it), and ran it again, with success.  

Once I got my app working, running the ‘pkg-dmg‘ was simple, and it worked brilliantly!  From mozilla-central, I stored only the folders leading to the ‘pkg-dmg’ file, then all the files in the folder.  So basically, ‘mozilla-central/build/package/mac_osx/‘ , then all the files in /mac_osx.  I made some modifications for my XRap release, by putting ‘pkg-dmg’ command in a script and calling it, but this is basically how it should work:

    var getWorkingDir= Components.classes["@mozilla.org/file/directory_service;1"]     .getService(Components.interfaces.nsIProperties)                    .get(“CurProcD”, Components.interfaces.nsIFile);

    var dmgLoc = getWorkingDir.clone();
    dmgLoc.append(“mozilla-central”);
    dmgLoc.append(“build”);
    dmgLoc.append(“package”);
    dmgLoc.append(“mac_osx”);
    dmgLoc.append(“pkg-dmg”);
    process.init(file);
    var args = ["--source ",applicationPath ," --target ",applicationPath + ".dmg"];
    process.run(true,args,args.length);

And work it did!  Here is an example, when I called it from bash

Mount and go!

When the wizard is started, it scans the system to get what platform it is working under, this will determine which page the wizard will go to next, and what scripts to run.  But before I get ahead of myself, the first page will ask the user to select where the application to be packaged is located.  I’m using the FilePicker dialog to get the end-user to select which folder is a XUL application, is makes it easy because the FilePicker will return the correct path format no matter what platform XRap is running on.

On the second page, it will matter which platform XRap is running on, because this is where the platform-dependent scripts will run to package the application for deployment.  As soon as the page is loaded, the script should start.  I just basically created three separate pages for each platform, and depending on what platform is scanned on the first page, the wizard will go to that page.  I have still been trying to get the progress bar to work, but it just seems to start and never stop, and the status box on the second page needs to be more informative.

The final page is just a ‘successful completion’ page, so that the user knows that the application was packaged succesFinally once the packager is complete, there is just a final completion page, just for accepting that the sfully.  I have an ‘error’ page, but I’ll have to refactor certain functions to return a false when there is an error.

By comparison, a normal XUL app will be enclosed in <window> tags, while a wizard will have the <wizard> tag.

<?xml version=”1.0″?>
<?xml-stylesheet href=”chrome://global/skin/” type=”text/css”?>

<wizard id=”testWizard” title=”First Wizard”
xmlns=”http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul”>
…
</wizard>

All wizards contain a series of pages for the end-user to progress through.  Just in the same fashion will each page be created, with its logic, followed by the next page, with it logic and so on.  Each new page will be enclosed in the <wizaradpage> tags.

<wizardpage>
<label value=”Welcome to my first wizard, enter your name and click next to continue…”/>
<textbox id=”name” />
</wizardpage>

<wizardpage>
<label value=”That is all to wizards”/>
</wizardpage>

There is a pretty good ‘Creating a Wizard‘ tutorial at Mozilla Developer, however there is not much more than what is covered here.  The strength of the wizard is in the flexability of its attributes, properties and methods, and the only way to see the versatility of this component, is to manipulate these features.

I will be revamping my XRap application to run as a wizard, where it will only execute certain scripts depending on what platfrom it is running on.  For example, since I won’t be able to create Mac packages on Windows or Linux, I don’t want to give the user the option of creating a Mac package if they are running on the latter.

>pkg-dmg –source <source-folder> –target <target-folder>

After pulling the latest code from mozilla-central, I located the script in ‘mozilla-central/build/package/mac_osx/pkg-dmg‘, unfortunately I don’t have access to a Mac, and will have to wait until next week to test out the script and my code.  But, just for fun I ran the script on my Linux box, and got repeated error messages that ‘hdiutil’ was not present.  Hdiutil is a Mac utility used for manipulating disk images, therefore an essential component for the pkg-dmg script.

Next step…Find a Mac! (not that hard, should be done next week)

…some explaination