Closed Bug 18433 Opened 20 years ago Closed 20 years ago

repackage resources into jar files


(Core :: Networking, defect, P3)






(Reporter: warrensomebody, Assigned: dprice)



(Keywords: perf, Whiteboard: [nsbeta2-]Exception Feature[7/17][UE1])

After figuring out how resource: URLs should really behave w.r.t. substitutions
and jar files (bug 18432) and completing the jar protocol, we need to convert
our existing html, xul and css files to use the new scheme.

As part of this conversion task, the build rules will need to zip up resources
into jar files according to how we want things to be packaged. I don't know if
this should be part of the make install phase, installing into a jar file in the
dist dir instead of just copying files, or whether it should be part of the
installer/packager that does this.

Note that we may want to run in a dual mode where resources may either be found
in jar files or in expanded directories (like java did with its classpath). One
reason for this is to avoid changing all the build rules right away. Another
reason is lack of an automatable zip utility for Mac. (This could be error prone
though -- where things work for debug builds but not release builds, etc.)
Blocks: 12834
Depends on: 12579, 18432
Target Milestone: M14
No longer blocks: 12834
Blocks: 12833
Summary: convert existing resource: URLs to new scheme → [BETA] repackage resources into jar files
Changing summary from: convert existing resource: URLs to new scheme
to: repackage resources into jar files
to make it more clear what this bug is.
Blocks: 18951
Blocks: 21564
Bulk move of all Necko (to be deleted component) bugs to new Networking

Blocks: 22176
Whiteboard: (py8ieh:ua.css)
Note: QA need the ability to change the ua.css file (and those it links to)
easily to track down CSS, HTML and {compat} bugs. If those files are put in a
jar then some alternate means of changing them must be left in.

Personally I would welcome the ability for the resource protocol to use both
jar(/zip/tar) files _and_ expanded directories. It would make customizing
Mozilla a lot easier... ;-)
I believe hyatt plans to support unpacked files overriding files in the archive
(to encourage people to make their customizations obvious/easy rather than
having to support unknown/unreliable archives). In addition, it's trivial with
a tool like WinZip to modify an archived file "in place", and not too much
harder using command-line tools.
No longer depends on: 12579
Blocks: 12579
No longer blocks: 12579
Depends on: 12579
Depends on: 24764
No longer depends on: 24764
Depends on: 24767
No longer depends on: 18432
Due to Beta indication in Summary, putting beta1 into keyword field.
Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: (py8ieh:ua.css) → [PDT+](py8ieh:ua.css)
Summary: [BETA] repackage resources into jar files → repackage resources into jar files
Please re-evaluate if this is really a PDT+ bug--removed the PDT+ from the 
status whiteboard for now. Looks like the main customers for this bug is the 
install team and they need to make it part of the install process. NOt sure if 
they have a PDT+ bug that depends on this one? If not, then is this really a 
PDT+ candidate? Please evaluate.
Whiteboard: [PDT+](py8ieh:ua.css) → (py8ieh:ua.css)
This bug depends on 24767--which Hyatt says should probably wait until after 
beta1. This does look like it will take a while to wrap up completely.
The install team will happily install whatever the product is. We think it 
looks bad to take 50+Mb on a FAT drive to install nav-only, but that's someone 
else's call.
I don't think anyone is arguing that this shouldn't be done by FCS, just that
it is not critical functionality for beta1. I personally agree that this is
probably not something which is required for beta1 so long as we release-note
it to explain why there are so many files.
Whiteboard: (py8ieh:ua.css)
PDT is willing to release note this disk-performance hit for beta1
Whiteboard: [PDT-]
Keywords: skins
Blocks: 29160
Shouldn't this bug be re-targetted for a current or future milestone, hopefully 
Mass-adding beta2 keyword to all skins bugs.
Keywords: beta2
Moving milestone to M16.
Target Milestone: M14 → M16
Keywords: nsbeta2
This bug does not directly require any skins--but it has the keyword "skins" as 
skins have a dependency on this bug.  
Keywords: beta2
Forgot to mention that I added the above comment as selmer was asking all bug 
owners who had the keyword skins to update their skins bugs with comments and 
Re-assigning this bug to Warren as it holds the skins keyword and is a little 
confusing. And as this is more like a tracking bug.

Opening 2 bugs -- which would be on demos of how to repackage resources into jar 
One bug for Mac (bug 38594) and 
one for windows/linux (bug 38593).
Assignee: gayatrib → warren
Putting on [nsbeta2+][5/16] radar.  This is a feature MUST complete work by 
05/16 or we may pull this feature for PR2.
Whiteboard: [PDT-] → [nsbeta2+][5/16][PDT-]
No longer depends on: 24767
Blocks: 24767
Blocks: 40642
Putting on [nsbeta2-] radar. Not critical to beta2.  But adding perf and nsbeta3 
keyword to get done for PR3.
Keywords: nsbeta3, perf
Whiteboard: [nsbeta2+][5/16][PDT-] → [nsbeta2-]
I thought we discussed this last week and agreed that it needs to be in for 
nsbeta2. The issue is that if we don't do it, we're not going to have a good 
story for skin developers (our primary target audience for beta2, right?), we're 
not going to uncover major bugs related to this feature, and our footprint is 
going to be 200M on disk.

Erasing nsbeta2- for reevaluation.
Whiteboard: [nsbeta2-]
Putting on nsbeta2+ radar.
Whiteboard: [nsbeta2+]
There was some question in .xpfe regarding the status of the "dual-mode" 
mentioned at the beginning of this bug. I would just like to chime in and state 
the importance of being able to run with skin files "unpacked". When creating a 
new skin, having to pack up the files before viewing a change would be a 
horrible burden on developers, I fear, and could end up having a deleterious 
affect on the number of people willing to skin moz. Others have the same 

The newsgroup thread was "zip/jar files and mozilla".

David's going to take this on now.
Assignee: warren → dprice
M16 has been out for a while now, these bugs target milestones need to be 
No longer blocks: 18951
No longer blocks: 21564
No longer blocks: 22176
Adding Exception Feature indication
Whiteboard: [nsbeta2+] → [nsbeta2+]Exception Feature
Depends on: 45155
Try to do this working around hyatts bug, see warren for ideas on this.  If not 
fixed by 7/17, we will nsbeta- this bug and fix right after PR2.
Whiteboard: [nsbeta2+]Exception Feature → [nsbeta2+]Exception Feature[7/17]
45155 has been fixed.  After some work with Warren today, chatzilla is working 
from a .jar file with only one major issue.  The menu item for chatzilla has 
disappeared from the tasks menu.  Warren and I are spreading out over the rest 
of the app creating the manifest files we'll need to repackage the rest of the 
chrome in .jar files.
created a manifest file for messenger, and at first glance it appears to be 
working correctly.
Per today's PDT, moving from [nsbeta2+] to [nsbeta2-]
Whiteboard: [nsbeta2+]Exception Feature[7/17] → [nsbeta2-]Exception Feature[7/17]
Blocks: 45937
all of the manifest files are completed.  I'll be testing with them tomorrow and 
talking to warren about the best way to flip the switch that turns this on.
Excellent work Dave! 

I'm still working on the zip code for the mac. Turns out the zip perl utility 
shipped with the mac is broken, but I got a suggestion from the author of how to 
work around it. I'll see if I can get it going tonight.
Manifest files have been checked in for content and locales.  Testing revealed 
the same failure to load an overlay that we saw with chatzilla.  Unfortunately 
this overlay is communicatorOverlay.xul and the browser fails to start without 
it.  This is will be the focus of my attention
We've been working hard, driving the Jar Packaging Stopper count to zero.  Right 
now we're very close, with only two Jar Packaging Stoppers remaining.  It 
crashes when the jar cache is cleared, and some files are not being loaded 
properly on startup.  

All of the manifests are in place.  Once once these problems disappear, I'll 
will add a switch to turn on the packaging.
Blocks: 46707
Keywords: UE1
Whiteboard: [nsbeta2-]Exception Feature[7/17] → [nsbeta2-]Exception Feature[7/17][UE1]
cc self.
This affects a lot of top mac issues. Adding nsmac1.
Keywords: nsmac1
Depends on: 49250
Can someone attach patches to turn this on? I need to get profiling with it on in 
my build ASAP.
I've got it in my tree at work, but I'm not at work today.
It looks like jar packaging is failing again.  It is failing to load the first 
.xul file for the profile manager.  It is in nsDocShell::InteralLoad() at a call 
to NS_ENSURE_SUCCESS(DoURILoad(aURI, ....  I traced it down a little farther and 
I think it is in NS_OpenURL()
Warren and I removed the threadsafe assertion I was seeing on Win2K.
He and hyatt fixed the hanging on startup problem
He figured out that is corrupting the images files it was copying

Everything appears to be happy on windows, asking ben and hyatt to test.
Working on getting Lunix and Mac going.
This has been turned on for windows.
Simon and I are working to get mac going
Depends on: 52065
Adding dependency on the mac bug 52826.
Depends on: 52826
We're in!!!
Closed: 20 years ago
Resolution: --- → FIXED
Keywords: beta1, skinsnsbeta1
No longer blocks: 46707
Keywords: UE1
You need to log in before you can comment on or make changes to this bug.