Closed
Bug 18433
Opened 25 years ago
Closed 24 years ago
repackage resources into jar files
Categories
(Core :: Networking, defect, P3)
Tracking
()
VERIFIED
FIXED
M16
People
(Reporter: warrensomebody, Assigned: dprice)
References
Details
(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.)
Reporter | ||
Updated•25 years ago
|
Reporter | ||
Updated•25 years ago
|
Summary: convert existing resource: URLs to new scheme → [BETA] repackage resources into jar files
Reporter | ||
Comment 1•25 years ago
|
||
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.
Bulk move of all Necko (to be deleted component) bugs to new Networking component.
Updated•25 years ago
|
Whiteboard: (py8ieh:ua.css)
Comment 3•25 years ago
|
||
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... ;-)
Comment 4•25 years ago
|
||
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.
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)
Updated•25 years ago
|
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.
Comment 9•25 years ago
|
||
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.
Comment 10•25 years ago
|
||
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)
Comment 11•25 years ago
|
||
PDT is willing to release note this disk-performance hit for beta1
Whiteboard: [PDT-]
Comment 12•24 years ago
|
||
Shouldn't this bug be re-targetted for a current or future milestone, hopefully M16?
Comment 15•24 years ago
|
||
This bug does not directly require any skins--but it has the keyword "skins" as skins have a dependency on this bug.
Keywords: beta2
Comment 16•24 years ago
|
||
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 status.
Comment 17•24 years ago
|
||
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 files. One bug for Mac (bug 38594) and one for windows/linux (bug 38593).
Assignee: gayatrib → warren
Status: ASSIGNED → NEW
Comment 18•24 years ago
|
||
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-]
Comment 19•24 years ago
|
||
Putting on [nsbeta2-] radar. Not critical to beta2. But adding perf and nsbeta3 keyword to get done for PR3.
Reporter | ||
Comment 20•24 years ago
|
||
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-]
Comment 22•24 years ago
|
||
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 impression. The newsgroup thread was "zip/jar files and mozilla". news://news.mozilla.org/39354C78.13850A4E%40netscape.com
Comment 24•24 years ago
|
||
M16 has been out for a while now, these bugs target milestones need to be updated.
Comment 25•24 years ago
|
||
Adding Exception Feature indication
Whiteboard: [nsbeta2+] → [nsbeta2+]Exception Feature
Comment 26•24 years ago
|
||
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]
Assignee | ||
Comment 27•24 years ago
|
||
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.
Assignee | ||
Comment 28•24 years ago
|
||
created a manifest file for messenger, and at first glance it appears to be working correctly.
Comment 29•24 years ago
|
||
Per today's PDT, moving from [nsbeta2+] to [nsbeta2-]
Whiteboard: [nsbeta2+]Exception Feature[7/17] → [nsbeta2-]Exception Feature[7/17]
Assignee | ||
Comment 30•24 years ago
|
||
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.
Reporter | ||
Comment 31•24 years ago
|
||
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.
Assignee | ||
Comment 32•24 years ago
|
||
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
Assignee | ||
Comment 33•24 years ago
|
||
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.
Updated•24 years ago
|
Keywords: UE1
Whiteboard: [nsbeta2-]Exception Feature[7/17] → [nsbeta2-]Exception Feature[7/17][UE1]
Comment 34•24 years ago
|
||
cc self.
Comment 36•24 years ago
|
||
Can someone attach patches to turn this on? I need to get profiling with it on in my build ASAP.
Reporter | ||
Comment 37•24 years ago
|
||
I've got it in my tree at work, but I'm not at work today.
Assignee | ||
Comment 38•24 years ago
|
||
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()
Assignee | ||
Comment 39•24 years ago
|
||
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 make-jars.pl 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.
Assignee | ||
Comment 40•24 years ago
|
||
This has been turned on for windows. Simon and I are working to get mac going
Reporter | ||
Comment 42•24 years ago
|
||
We're in!!!
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•24 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•