328901 - Split MozillaInterfaces.jar

Status: RESOLVED FIXED

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

Description

[jhp (no longer active)]

It would be best to split MozillaInterfaces.jar, in order to make it more maintainable from the client side of things.  Here's what I have in mind:

    * MozillaGlue.jar (or XPCOMGlue.jar, whatever) - This jar would be roughly equivalent to xpcomglue.dll.  It would contain all the bootstrapping code to find a valid XULRunner install and start embedding, as well as the convenience methods like |GetComponentManager|, etc.  The code would be forward compatible like the current glue code is.
    * MozillaInterfaces.jar - Roughly equivalent to the C headers in the SDK.  This jar would just contain the Java-fied public Mozilla interfaces.  In fact, this could be split into two separate jars, one each for frozen and non-frozen interfaces.  This might help clients mostly stick to frozen interfaces, and they would be guaranteed that using a given version of the frozen interfaces jar would work with future XULRunner releases.  Or, instead of separating the interfaces into different jars, we could add a comment for all of the frozen interfaces.

Unfortunately, since I use the nsInterfaceInfoManager to generate the Java interfaces, there is no easy way to differentiate between frozen and non-frozen interfaces.  And in order to switch back to using xpidl.exe, some bugs need to be fixed (such as bug 324026).

Comment 1

[jhp (no longer active)]

Attachment: patch

This patch splits the jar into MozillaGlue.jar and MozillaInterfaces.jar.  This also sets up some make rules for creating a Java library.

Unfortunately, due to lack of foresight on my part, this patch requires doing some CVS moves of the code (who handles that?):

cvs move extensions/java/xpcom/interfaces/*.java
   extensions/java/xpcom/interfaces/org/mozilla/xpcom/
cvs move extensions/java/xpcom/XPCOMException.java
   extensions/java/xpcom/interfaces/org/mozilla/xpcom/
cvs move extensions/java/xpcom/gen-nsError.pl
   extensions/java/xpcom/interfaces/
cvs move extensions/java/xpcom/XPCOMJavaProxy*.java
   extensions/java/xpcom/src/org/mozilla/xpcom/interal/
cvs move extensions/java/xpcom/src/*Impl.java
   extensions/java/xpcom/src/org/mozilla/xpcom/internal/
cvs move extensions/java/xpcom/*.cpp
   extensions/java/xpcom/src/
cvs move extensions/java/xpcom/*.h
   extensions/java/xpcom/src/
cvs remove extensions/java/xpcom/XPCOMPrivate.java
cvs remove extensions/java/xpcom/build

Comment 2

[jhp (no longer active)]

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

bsmedberg, what do you think of this split?  As I mentioned previously, eventually it would be good to also split the interfaces into a frozen and a non-frozen jar (but other bugs need to be fixed before that can happen).

Comment 3

[Benjamin Smedberg]

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

I'll get to this Thursday, hopefully.

Comment 4

[jhp (no longer active)]

Hmm, looks like I never tested this on Win32.  For that to work, I had to put quotes around the _JAVA_SOURCEPATH and _JAVA_CLASSPATH values, as well as to prepend "$(CYGWIN_WRAPPER)" to the $(JAVAC) line.

Comment 5

[jhp (no longer active)]

Attachment: patch using xpidl (checked in)

This patch is based on the xpidl patch from bug 333618.  Cleans up the rules from the previous patch.  The CVS moves from comment #1 still apply.

Comment 6

[Benjamin Smedberg]

Comment on attachment 226653 [details] [diff] [review]
patch using xpidl (checked in)

>+##
> # Temporarily copy these not only to dist/sdk/lib but to dist/bin/sdk/lib
>+##
> 
> TEMP_SDK_DIR = $(DIST)/bin/sdk/lib
> 
> $(TEMP_SDK_DIR)::
> 	$(NSINSTALL) -D $@

Remove this now that we're releasing SDKs again?

Comment 7

[jhp (no longer active)]

Checked in to trunk, and seems to be building fine on Linux XULRunner tbox.  ->FIXED

Comment 8

[jhp (no longer active)]

Attachment: sdk copy patch (checked in)

The jars aren't getting properly copied into the SDK.  I set NO_DIST_INSTALL to prevent MozillaGlue.jar from getting copied to dist/bin, but this also prevents them from getting copied to dist/sdk/lib.  Benjamin, is this patch the correct way to handle this?

Comment 9

[Benjamin Smedberg]

Comment on attachment 240353 [details] [diff] [review]
sdk copy patch (checked in)

That's not a bad way to do it.