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•25 years ago
|
||
Shouldn't this bug be re-targetted for a current or future milestone, hopefully
M16?
Comment 15•25 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•25 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•25 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•25 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•25 years ago
|
||
Putting on [nsbeta2-] radar. Not critical to beta2. But adding perf and nsbeta3
keyword to get done for PR3.
Reporter | ||
Comment 20•25 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•25 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•25 years ago
|
||
M16 has been out for a while now, these bugs target milestones need to be
updated.
Comment 25•25 years ago
|
||
Adding Exception Feature indication
Whiteboard: [nsbeta2+] → [nsbeta2+]Exception Feature
Comment 26•25 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•25 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•25 years ago
|
||
created a manifest file for messenger, and at first glance it appears to be
working correctly.
Comment 29•25 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•25 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•25 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•25 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•25 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•25 years ago
|
Keywords: UE1
Whiteboard: [nsbeta2-]Exception Feature[7/17] → [nsbeta2-]Exception Feature[7/17][UE1]
Comment 34•25 years ago
|
||
cc self.
Comment 36•25 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•25 years ago
|
||
I've got it in my tree at work, but I'm not at work today.
Assignee | ||
Comment 38•25 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•25 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•25 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
•