325380 - Eclipse update site for JavaXPCOM jars from XULRunner 1.8.0.1

Status: VERIFIED FIXED

(mozilla.org Graveyard :: Server Operations, task)

Description

[jhp (no longer active)]

We should make the MozillaInterfaces.jar file (part of JavaXPCOM; defines Java interfaces for Mozilla) from XULRunner 1.8.0.1 available as an Eclipse update site.  This would allow an Eclipse user to easily pull this jar into his/her project, through Eclipse's update facility.

Mike Morgan mentioned using the https://pfs.mozilla.org site for this purpose.

Comment 1

[jhp (no longer active)]

Attachment: patch

This diff doesn't show much, since most of the code is in the binary jar files.  I decided on using https://pfs.mozilla.org/java/update as the URL, which corresponds to the locations of the files in this patch.

Comment 2

[jhp (no longer active)]

Attachment: feature.xml

This is the feature.xml file, from within the feature jar file.  This defines the plugin, as well as providing some additional information (such as license, update site).

Comment 3

[Michael Morgan [:morgamic]]

John, does this fit in with the way PFS is currently set up?

Comment 4

[jhp (no longer active)]

So are we just waiting for jst for this to move forward?  Is pfs.mozilla.org the best location for this?

Comment 5

[Michael Morgan [:morgamic]]

Yeah, I wanted jst to weigh in.

There was also the question of whether or not the link to this update file needs to be obfuscated for EULA/Liability reasons like most of the plugins are.  Is this something that needs to happen?

Comment 6

[Benjamin Smedberg]

This is a Mozilla download and does not need to be obscured.

Comment 7

[Michael Morgan [:morgamic]]

Okay, good deal.

Comment 8

[Michael Morgan [:morgamic]]

CC'ing server-ops.  Do you guys think PFS would be the place for this, or would it be more appropriate to put it on stage?

Comment 9

[jhp (no longer active)]

(In reply to comment #5)
> There was also the question of whether or not the link to this update file
> needs to be obfuscated for EULA/Liability reasons like most of the plugins are.
>  Is this something that needs to happen?

I'm not 100% sure what you mean by "obfuscated" in this case, but the way Eclipse updates work is that when you select the software you wish to install, before you can actually install, it shows you the associated license agreement.  You cannot install unless you agree to it.  The attached "feature.xml" file has the license agreement.

Comment 10

[Dave Miller [:justdave]]

Does that happen at install time when you run the installed?  There's existing plugins with the same thing (have to agree to EULA) except they make you agree before you download, hence the "obfuscated" URL (actually a unique token issued when you agree to the EULA)

Comment 11

[jhp (no longer active)]

(In reply to comment #10)
Yes, you have to agree before you download the plugin code.

Comment 12

[alanjstr]

Ok, so we want to host a file and are just looking for the best place to put it?  I don't think pfs would be the best place in that case.  We're just serving a static file, right?  PFS is the plugin finder service.  

Comment 13

[Johnny Stenback (:jst)]

(In reply to comment #3)
> John, does this fit in with the way PFS is currently set up?

Not really. But I honestly don't know where these XML files etc fit in. PFS so far has been for traditional NPAPI plugins and that only. Having said that, I don't have a problem with these files living on pfs.mozilla.org, but I don't think they really match anything else we've got on there.

Comment 14

[jhp (no longer active)]

Well, if not PFS, then where?  What about the main update site: aus2.mozilla.org/update/eclipse?  Or addons.mozilla.org/update/eclipse?

Comment 15

[alanjstr]

How about ftp.mozilla.org/pub/mozilla.org/JavaXPCOM/MozillaInterfaces.jar

Comment 16

[jhp (no longer active)]

It's not as easy as that.  You just mention a JAR file.  But this bug is about putting up an Eclipse plugin (which is basically an encapsulation of the MozillaInterfaces.jar file) and the accompanying files to allow updates to work (see the attached "patch").  Of course, ftp.mozilla.org/pub/mozilla.org/JavaXPCOM/... would work just fine.

This bug isn't about adding these files to PFS;  it's about finding the best place on Mozilla's servers to add this directory structure.  If the people copied here think that ftp.mozilla.org is a good place for it, then great!

Comment 17

[Michael Morgan [:morgamic]]

Reassigning to server-ops.  Could you guys find a place on stage to host these files?  Since it's not a regular plugin it doesn't really fit into the rest of PFS.

Comment 18

[jhp (no longer active)]

Just talked to the group here at IBM that wants to use JavaXPCOM in Eclipse, and they also are using Rhino.  So maybe this should be more generalized.  We should do ftp.mozilla.org/pub/eclipse-update, and the site.xml file there would list both "Mozilla Java APIs" (JavaXPCOM) and "Javascript for Java (Rhino)".  That way, both of these would be available to Eclipse users from a common mozilla.org site.

Comment 19

[Michael Morgan [:morgamic]]

Alright, this has been sitting here long enough.

Javier, we've talked about it, and we don't see anything wrong with using PFS.  Where it goes is arbitrary and not important, what is important is that we get it up for you guys.

What I'll need though is a complete tar of what needs to go in the /java directory off of PFS.  Could you attach it?  Thanks. 

Comment 20

[jhp (no longer active)]

http://javier.pedemonte.us/mozilla/mozilla_update_site.zip

Zip file with the Eclipse update site.  This goes along with what I said in comment #18: this update site contains both the JavaXPCOM and Rhino jars.  It is set up for the user to find it at http://pfs.mozilla.org/eclipse-update/.

Comment 21

[Michael Morgan [:morgamic]]

Javier, do we still need feature.xml?  If so, and you want the eclipse-updates/ URI then we'll have to change the blurb at the bottom of it:

   <url>
      <update url="https://pfs.mozilla.org/java/update/"/>
   </url>

Shouldn't we change it?

Comment 22

[Michael Morgan [:morgamic]]

I guess you meant to have the .zip take the place of feature.xml for generalization, but I need to verify that you want to put this stuff up without the license information that was in feature.xml -- is that what you want?

If not, we should get an updated version of site.xml with the license information in there so we don't just throw this to the wolves... :)

Comment 23

[jhp (no longer active)]

I attached the feature.xml file as an example of what is listed in it.  This file is actually contained in one of the feature.jar files.  I have updated the URL address there.  So the only thing that needs to go on the site is the zip file, unzipped.

The licensing information is also contained in each feature.xml file, and is displayed to the user before the plugin jar is downloaded.  Hope that makes sense!

Comment 24

[Michael Morgan [:morgamic]]

Okay - thanks for clarifying.  I'm putting up the files right now.

Comment 25

[Michael Morgan [:morgamic]]

Checked in -- .jar files with -kb (as binaries).  Should be live pending progress of bug 327644, which an update on production.

Comment 26

[Michael Morgan [:morgamic]]

Should be live.  Please verify.  Thanks.  :)

Comment 27

[jhp (no longer active)]

I kept looking for https://pfs.mozilla.org/eclipse-update/site.xml, but it looks like it actually ended up at https://pfs.mozilla.org/plugins/eclipse-update/site.xml.  And while Eclipse will find this just find, it means that the internal update URLs for the plugins are wrong.

So Mike, should we just update the internal URLs, or actually get this set at https://pfs.mozilla.org/eclipse-update/.

Comment 28

[jhp (no longer active)]

Actually, the internal update URLs need to be changed anyway, since I have them using "http" rather than "https", and this causes a redirect, which the Eclipse update tool doesn't like.  So I just went ahead and changed the internal update URLs to https://pfs.mozilla.org/plugins/eclipse-update/.  Files available at http://javier.pedemonte.us/mozilla/mozilla_update_site.zip.

Comment 29

[jhp (no longer active)]

@#%&*!!! Looks like some versions of Eclipse don't like "https" update sites.  Unfortunately, I was testing with a later version, so it worked fine for me.  But it failed for a co-worker of mine using an older version.  So https://pfs.mozilla.org/ won't work!

Comment 30

[Benjamin Smedberg]

I am not excited about shipping downloadable code over http without at least a https-verified checksum or signature.

Comment 31

[alanjstr]

We have quite a lot on ftp.m.o that doesn't have that.  Not that it would be hard to upload that too.

Comment 32

[jhp (no longer active)]

The reason some Eclipse versions crap out on https is that they have trouble reading the certificate and don't handle it well.  It looks like in the latest versions, they rolled their own ssl socket support to properly handle this.  Oh well, one more time...

Mike suggested ftp.mozilla.org.  So the update site URL would be http://ftp.mozilla.org/pub/mozilla.org/eclipse-update/.  I'll update the package on my site with this new URL.

Comment 33

[jhp (no longer active)]

Package update with URL in comment #32.  File at http://javier.pedemonte.us/mozilla/mozilla_update_site.zip.

Comment 34

[jhp (no longer active)]

(In reply to comment #30)
> I am not excited about shipping downloadable code over http without at least a
> https-verified checksum or signature.

This won't really help any from an Eclipse point of view.  An Eclipse user will just go to the "Find and Install" feature (a.k.a. update) and enter a URL.  Then Eclipse takes care of retrieving the info, displaying the license, and then downloading the actual plugin.  The user never sees the actual directory listing of the site, or downloads the plugin to a directory.  So a checksum would not be used.

Comment 35

[jhp (no longer active)]

Move to Server Ops component.

Comment 36

[Dave Miller [:justdave]]

Who needs to sign off on creating a top-level directory on the ftp site under /pub/mozilla.org?

Comment 37

[jhp (no longer active)]

OK, so this bug seems to have caused some confusion, so I will attempt to answer some questions here.

> Why should this be hosted on mozilla.org and not on eclipse.org?

Because the code itself is mozilla.org code (JavaXPCOM and Rhino).  This is just about providing a convenient installation mechanism for these two products, such that it can be easily pulled in by an Eclipse user.

> Why do we need a central Eclipse update site?  Why not have each plugin alongside the downloads for that product (i.e. the Rhino Eclipse plugin alongside the other Rhino downloads).

This is certainly doable, but it works best to have it all in one location.  An Eclipse user inputs the location into the Eclipse installation/update tool, and it lists the available software (screenshot here: http://help.eclipse.org/help31/topic/org.eclipse.platform.doc.user/whatsNew/images/select-required.png).  Each product has it's own category, under which are all the available downloads for that product.  So there would be a "Mozilla Javascript for Java" category, under which would be all of the Rhino versions.

> Who gave the authority to make these plugins available on mozilla.org servers?

This has been discussed between my higher ups (at IBM) and the higher ups at the Mozilla Foundation/Corp (Mitchell Baker, et. al.).

Let me know if I missed something.

Comment 38

[Mike Shaver (:shaver emeritus)]

We're not creating a new top-level for this.  Eclipse plugins are like installers and .mars and other distribution mechanisms; they should live in the tree alongside other packages of the same or materially-the-same code.

So we're going with pub/xulrunner/eclipse/ for site.xml, and pub/xulrunner/releases/1.8.0.1/eclipse/ for the per-version plugins.  I've created the dirs, and am therefore resolving this bug.

Comment 39

[jhp (no longer active)]

It looks like the directories were not created with the correct permissions.  We can't copy files into them.  The owner for the "eclipse" dirs is "root", whereas for all the other dirs, it's "cltbld".  Can someone with the correct permissions fix this, please?

Comment 40

[Dave Miller [:justdave]]

(In reply to comment #39)
> Can someone with the correct permissions fix this, please?

I've created a new group called 'xulrunner' and added the users 'pedemonte' and 'mkaply' to that group.  It was suggested to also add bsmedberg to it, but I can't figure out what his stage username is if he has one.

The xulrunner group has been given write access to the /pub/mozilla.org/xulrunner/eclipse directory.

Comment 41

[jhp (no longer active)]

OK, really fixed now.  Files:
ftp.mozilla.org/pub/mozilla.org/xulrunner/eclipse/site.xml
ftp.mozilla.org/pub/mozilla.org/xulrunner/eclipse/features/org.mozilla.xpcom.feature_1.8.0.1.jar
ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.0.1/eclipse/org.mozilla.xpcom_1.8.0.1.jar

Comment 42

[jhp (no longer active)]

Eclipse install works well. ->VERIFIED