Last Comment Bug 342541 - JavaXPCOM jars not copied into XUL.framework
: JavaXPCOM jars not copied into XUL.framework
Status: RESOLVED FIXED
: fixed1.8.0.5, fixed1.8.1
Product: Core Graveyard
Classification: Graveyard
Component: Java to XPCOM Bridge (show other bugs)
: 1.8 Branch
: PowerPC Mac OS X
: -- normal (vote)
: ---
Assigned To: jhp (no longer active)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-23 10:35 PDT by jhp (no longer active)
Modified: 2014-09-24 05:43 PDT (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch (701 bytes, patch)
2006-06-23 10:37 PDT, jhp (no longer active)
benjamin: review+
jaymoz: approval1.8.0.5+
darin.moz: approval1.8.1+
Details | Diff | Splinter Review

Description jhp (no longer active) 2006-06-23 10:35:17 PDT
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).
Comment 1 jhp (no longer active) 2006-06-23 10:37:15 PDT
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.
Comment 2 Steven Michaud [:smichaud] (Retired) 2006-06-23 10:52:41 PDT
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 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2006-06-26 13:13:31 PDT
Comment on attachment 226804 [details] [diff] [review]
patch

This has nothing to do with JEP.
Comment 4 jhp (no longer active) 2006-06-26 14:51:28 PDT
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.
Comment 5 jhp (no longer active) 2006-06-27 11:42:49 PDT
Forgot to mention that this is checked into the trunk.  -> FIXED
Comment 6 Daniel Veditz [:dveditz] 2006-06-27 13:55:58 PDT
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 Benjamin Smedberg AWAY UNTIL 2-AUG-2016 [:bsmedberg] 2006-06-27 13:57:42 PDT
I'm going to presume that we haven't done spins of XULRunner yet, and this is XR-only.
Comment 8 Daniel Veditz [:dveditz] 2006-06-28 09:35:38 PDT
> 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 Darin Fisher 2006-06-28 20:47:34 PDT
Comment on attachment 226804 [details] [diff] [review]
patch

a=darin on behalf of drivers
Comment 10 Jay Patel [:jay] 2006-06-29 13:47:17 PDT
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.

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