327654 - nsIXMLHTTPRequest class not included in MozillaInterfaces.jar

Status: RESOLVED FIXED

(Core Graveyard :: Java to XPCOM Bridge, defect)

Description

[jhp (no longer active)]

Someone noticed that nsIXMLHTTPRequest.class is not in MozillaInterfaces.jar from XULRunner 1.8.0.1, but is included in the one from the XULRunner trunk.

It looks like this is a result of the order in which directories are processed in the top level Makefile.  The 'extensions/java' dir is in tier_50, but the remaining extensions (such as xmlextras, to which nsIXMLHTTPRequest.idl belongs) are handled in tier_99.

This is somewhat better on the trunk, since many of the main extensions are now in tier_9 (before 'extensions/java'), but some extensions still come later.

The GenerateJavaInterfaces util uses nsInterfaceInfoManager to get all of the available interfaces, and it will only read from the available .xpt files.  So this step needs to come after all the IDL files have been processed.

Comment 1

[jhp (no longer active)]

Attachment: patch

This patch fixes it, but is more of a band-aid.  In the long run, we should probably move the interface generation and any other jars that depend on it to their own sub-directory.

Comment 2

[Benjamin Smedberg]

Comment on attachment 212516 [details] [diff] [review]
patch

This sucks in general: we should be hooking into xpidl and the XPIDLSRCS targets in rules.mk and generating on the fly.

Comment 3

[jhp (no longer active)]

That still won't fix this, since at the end, we need to compile the Java classes.  So we would still need to do something after all of the IDL files have been parsed.

Comment 4

[jhp (no longer active)]

Comment on attachment 212516 [details] [diff] [review]
patch

We should get this in for XULRunner 1.8.0.2.

Comment 5

[Daniel Veditz [:dveditz]]

Comment on attachment 212516 [details] [diff] [review]
patch

approved for 1.8.0 branch, a=dveditz for drivers

Comment 6

[jhp (no longer active)]

Checked in to trunk.