Closed Bug 507575 Opened 10 years ago Closed 8 years ago

Create Eclipse update site for XULRunner 1.9.1


(Release Engineering :: General, defect)

Not set


(Not tracked)



(Reporter: jacek.p, Unassigned)



(1 file)

71.24 KB, application/x-zip-compressed
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/ Safari/530.5
Build Identifier: XULRunner 1.9.1

Please provide an easy way to install latest XULRunner library in Eclipse to simply integrate it with Java Eclipse based applications.

This was done in history, e.g in bug 325380 and resulted with:

Zend Technologies would like to contribute and maintain the updated package, exactly the same as previous built by Javier Pedemonte from IBM, except that it would now contain XULRunner version 1.9.1.

We depend on that, to be able to further grow Ajax Tools Framework available at

Reproducible: Always
The refreshed update site that would be a good candidate to publish is ready for at:

Someone would have to download and unzip it.
I assumed that, after unzipping, it would be available at:

It contains a kind of table of contents (site.xml), which describes the contents of the update site to Eclipse download mechanism. Next there are two files: artifacts.jar and content.jar - those are the cached information about available downloads.
Further, "features" directory contains downloadable packages descriptions - there are two packages - one for XPCOM and one for XULRunner. They are all labeled with Mozilla MPL license as it was previously done in bug 325380. XPCOM feature is platform independent package and contains single plug-in (plugins/org.mozilla.xpcom_1.9.1.0_20090731).
XULRunner feature is platform dependent and contains three plug-ins for 3 main platforms supported by Mozilla: plugins/org.mozilla.xulrunner.win32.win32.x86, plugins/org.mozilla.xulrunner.gtk.linux.x86, plugins/org.mozilla.carbon.macosx

Features and plug-ins are all marked with four digit version number plus build id - that identifies this particular build made by me on 2009-07-31. In case I messed anything, plug-ins can be updated with higher version/build number.

Please let me know if you have any questions or concerns.
->mfinkle for investigation
Assignee: server-ops → nobody
Component: Server Operations → Release Engineering: Custom Builds
Ever confirmed: true
QA Contact: mrz → custom-builds
Assignee: nobody → mark.finkle
last days I was working on automatizing building Eclipse update site internally at Zend. As a result there's now this build available:

It's basically the same content as the previous one.

Mfinkle, how do we proceed now?

If you're interested I'd be happy to setup a similar infrastructure to build everything automatically on Mozilla side.
I'm looking over this bug again and I see I did not described clearly enough how the file that I propse was built.

It's an update to what Javier did.
I have downloaded the currently most recent release from
That's site.xml and files from features/ and plugins/ directory.
Next I had to replace XULRunner with 1.9.1 contents.
To do that and to be able to make such updates easily in future, I used Eclipse and created Eclipse plug-in projects and Eclipse feature projects for all plugins and features and copied jars contents to those projects.

Next, replaced /xulrunner folders inside org.mozilla.xulrunner.* plugins, replaced MozillaInterfaces.jar in org.mozilla.xpcom plugin and added MozillaGlue.jar to org.mozilla.xpcom plugin.

Next updated all plugins and features versions from to

Last part is building features and plugins to make them ready for consumption. For that I used Eclipse PDE Build.
Because of changes in Eclipse Update/Install Manager, the site.xml was replaced by content.jar and artifact.jar which are generated automatically by PDE Build based on features descriptions.

Mark F., let me know if you have any concerns.

Thanks for the explanation. I'll take a look at the files soon. I'll likely have some question for you when I do, since I am not an Eclipse user.
Attached are Ant scripts to build the discussed update site.
This is the core - build scripts for all parts. There's still needed a main build.xml to build complete update site zip.
I have documented all steps required to build Eclipse update site for Mozilla XULRunner at

I also published complete build scripts (attachment 1 [details] [diff] [review] and more) to Eclipse CVS to make it easier for anyone to build such an update site - link to them in above bugzilla.

However it's still high entry barier for Eclipse novice users, who would just want to run their Eclipse bits with XULRunner, rather than packaging it :-)
have you had any chance to look at this bug?
(In reply to comment #8)
> Mark,
> have you had any chance to look at this bug?

I have not forgotten, just got pretty busy. I will start on this soon.
I would really like to thank Zend for their efforts in creating XUL runner bundles.

These bundles are really important as most Eclipse-based IDEs that work with web technologies (PHP, AJAX, J2EE) need them to work with JavaScript. Currently they are available only from proprietary site (
Note: I did the same thing before, and it appeared that simply replacing interfaces and xulrunner is not enough. I.e. downoading a file via clicking a link causes xulrunner 1.9 to crash instead of save dialog (tested both on mac and windows). Thats because of binary incompatibility of xulrunner 1.9 and xpcom native libraries from xulrunner 1.8 eclipse plugin.

Can you point me where sources of xulrunner 1.8 eclipse plugin are?
(In reply to comment #11)
all true, java application have to have hard dependency on javaxpcom 1.8 or 1.9, and be compiled against that version.

javaxpcom 1.8 java source code is in mozilla/extensions/javaxpcom in Mozilla repository.
If you mean the packaging (eclipse feature and plug-in) I have only found bug 325380 which discusses how to put those on Mozilla ftp, now how they were made.
have you had any chance to look at this bug?
Found during triage. 

From email w/mfinkle, he hasnt had time to look at this, and wont for a while either, so we decide to find someone else to work on it.

This bug is so old (2009!), I need to ask if this is still needed, and if so, is the problem description still accurate?
Assignee: mark.finkle → nobody
Component: Release Engineering: Custom Builds → Release Engineering
QA Contact: custom-builds → release
No, with the removal of JavaXPCOM from XULRunner this is not something we should do.
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: → Release Engineering
You need to log in before you can comment on or make changes to this bug.