JavaXPCOM jars not copied into XUL.framework

RESOLVED FIXED

Status

Core Graveyard
Java to XPCOM Bridge
RESOLVED FIXED
11 years ago
3 years ago

People

(Reporter: jhp (no longer active), Assigned: jhp (no longer active))

Tracking

({fixed1.8.0.5, fixed1.8.1})

1.8 Branch
PowerPC
Mac OS X
fixed1.8.0.5, fixed1.8.1

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

11 years ago
The JavaXPCOM jars (MozillaInterfaces.jar and javaxpcom.jar) are built at the end of tier_99, in order to pick up all of the available interfaces.  However, since they are built during the 'lib' phase, they don't get copied into the XUL.framework directory (in xulrunner/app/Makefile.in).
(Assignee)

Comment 1

11 years ago
Created attachment 226804 [details] [diff] [review]
patch

Easy fix is to create the jars during the 'export' phase.  I want to get this in as soon as possible in order to make 1.8.0.5.  This is just a simple patch;  I'm reworking the Makefile rules in another bug.
Attachment #226804 - Flags: review?(benjamin)
Here's a somewhat off-topic question:

In what way (if any) does JavaXPCOM interact with the Java Embedding
Plugin (http://javaplugin.sourceforge.net, now bundled with all
Mozilla.org browsers)?

And if so, is there any possibility that this change will interfere
with the workings of the JEP?

Comment 3

11 years ago
Comment on attachment 226804 [details] [diff] [review]
patch

This has nothing to do with JEP.
Attachment #226804 - Flags: review?(benjamin) → review+
(Assignee)

Comment 4

11 years ago
Comment on attachment 226804 [details] [diff] [review]
patch

This is a very low risk patch, XULRunner only, which makes it so the JavaXPCOM jars are packaged correctly for MacOSX.  I'm not sure if it is too late for 1.8.0.5, but it would be best to get this into the 1.8.0.x nightlies as soon as possible.
Attachment #226804 - Flags: approval1.8.1?
Attachment #226804 - Flags: approval1.8.0.5?
(Assignee)

Comment 5

11 years ago
Forgot to mention that this is checked into the trunk.  -> FIXED
(Assignee)

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
We're past code-freeze for 1.8.0.5 but I guess we can keep this on the radar in case we need to do a re-spin.

Comment 7

11 years ago
I'm going to presume that we haven't done spins of XULRunner yet, and this is XR-only.
> I'm going to presume that we haven't done spins of XULRunner yet, and this is
> XR-only.

But the relteam has tagged the tree already. Don't XULRunner builds use the same tag?

Looks like there's a security bug that didn't get entirely fixed, stay tuned, we can get this in.

Comment 9

11 years ago
Comment on attachment 226804 [details] [diff] [review]
patch

a=darin on behalf of drivers
Attachment #226804 - Flags: approval1.8.1? → approval1.8.1+
(Assignee)

Updated

11 years ago
Keywords: fixed1.8.1

Comment 10

11 years ago
Comment on attachment 226804 [details] [diff] [review]
patch

approved for 1.8.0 branch, a=jay for drivers.  please land asap, so we can
respin and get RC2 out for testing.
Attachment #226804 - Flags: approval1.8.0.5? → approval1.8.0.5+
(Assignee)

Updated

11 years ago
Keywords: fixed1.8.0.5
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.