Last Comment Bug 327654 - nsIXMLHTTPRequest class not included in MozillaInterfaces.jar
: nsIXMLHTTPRequest class not included in MozillaInterfaces.jar
Status: RESOLVED FIXED
[nvn-dl]
: fixed1.8.0.2, fixed1.8.1
Product: Core Graveyard
Classification: Graveyard
Component: Java to XPCOM Bridge (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: jhp (no longer active)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-17 11:52 PST by jhp (no longer active)
Modified: 2014-09-24 05:43 PDT (History)
1 user (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch (1.93 KB, patch)
2006-02-20 13:06 PST, jhp (no longer active)
benjamin: review+
dveditz: approval1.8.0.2+
Details | Diff | Review

Description jhp (no longer active) 2006-02-17 11:52:13 PST
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) 2006-02-20 13:06:24 PST
Created attachment 212516 [details] [diff] [review]
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 [:bsmedberg] 2006-02-21 12:46:59 PST
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) 2006-02-21 13:00:01 PST
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) 2006-02-21 13:00:51 PST
Comment on attachment 212516 [details] [diff] [review]
patch

We should get this in for XULRunner 1.8.0.2.
Comment 5 Daniel Veditz [:dveditz] 2006-02-22 12:37:09 PST
Comment on attachment 212516 [details] [diff] [review]
patch

approved for 1.8.0 branch, a=dveditz for drivers
Comment 6 jhp (no longer active) 2006-02-23 14:25:16 PST
Checked in to trunk.

Note You need to log in before you can comment on or make changes to this bug.