507575 - Create Eclipse update site for XULRunner 1.9.1

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Jacek Pospychala]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.172.37 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:
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/eclipse/

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 www.eclipse.org/atf



Reproducible: Always

Comment 1

[Jacek Pospychala]

The refreshed update site that would be a good candidate to publish is ready for at:
www.cs.put.poznan.pl/jpospychala/mozilla_update_site.zip

Someone would have to download and unzip it.
I assumed that, after unzipping, it would be available at:
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.9.1/contrib/eclipse/

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

Comment 2

[Benjamin Smedberg]

->mfinkle for investigation

Comment 3

[Jacek Pospychala]

fyi,
last days I was working on automatizing building Eclipse update site internally at Zend. As a result there's now this build available:
http://il-it.zend.com/public/xulrunner-1.9.1.0_v20090806-1550-47Q26nmB55W5T5N28KK5.zip

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.

Comment 4

[Jacek Pospychala]

Hi'
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
http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/eclipse/
That's site.xml and files from features/ and plugins/ directory.
Next I had to replace XULRunner 1.8.1.3 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 1.8.1.3 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 1.8.1.3 to 1.9.1.0_buildid.

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.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

Jacek,

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.

Comment 6

[Jacek Pospychala]

Attachment: xulrunner-updatesite-releng

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.

Comment 7

[Jacek Pospychala]

Mark,
I have documented all steps required to build Eclipse update site for Mozilla XULRunner at http://wiki.eclipse.org/ATF/XULRunner

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

Comment 8

[Jacek Pospychala]

Mark,
have you had any chance to look at this bug?

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

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

Comment 10

[Eugene Ostroukhov]

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 (zend.com).

Comment 11

[Slava Nadvorny]

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?

Comment 12

[Jacek Pospychala]

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

Comment 13

[ReimerStudt]

Mark,
have you had any chance to look at this bug?

Comment 14

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

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?

Comment 15

[Benjamin Smedberg]

No, with the removal of JavaXPCOM from XULRunner this is not something we should do.