Closed Bug 41567 Opened 24 years ago Closed 6 years ago

Need to remove debug and test files from the res directory

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: sfraser_bugs, Unassigned)

References

Details

The /res directory in the application directory should be eliminated before 
shipping; any required files in there should be moved into /chrome.
cc morse: some wallet/singsong stuff goes into res.

So are there any files that cannot go into chrome:/? Do we actually need a place 
to put non-UI files? If so, I suggest 'resources'. On Mac, this should go into 
the Essential Files folder.

Does this mean that a hard-coded URI like "resource:/res/quirk.css" will have to 
change?
Yes. You should certainly be using a chrome: URL for things like that.

Per ben..
"As part of the skinnability drive for nsbeta2, and for platform
cleanliness for mozilla, many of the resource files under
mozilla/xpfe/global/resources are being refactored or moved int
xpfe/communicator."

POutting on [nsbeta2+] radar.
Keywords: nsbeta2
Whiteboard: [nsbeta2+]
Sorry for the spam.  New QA Contact for Browser General.  Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
Wallet tables are now out of the res directory.  Simon, res never had any 
"singsong" stuff, whatever that is.
I meant single signon, of course (as implemented in the memorable singsign.cpp) 
;)

Res never had any single signon stuff in it.
David: This is part of the "repackage into jar files" bug. As you see our build 
system copying things to the dist/bin/res directory, you should investigate 
what should be the appropriate jar file for these things (e.g. core.jar), and 
make you jar packaging put them in the new place. You'll also have to find and 
change any resource: urls to be chrome: urls that point to the new file's 
location.
Assignee: warren → dprice
David: See my last comment on this bug.
FYI...
repackage resources into jar files bug is
http://bugzilla.mozilla.org/show_bug.cgi?id=18433
Per today's PDT, moving from [nsbeta2+] to [nsbeta2-]
Whiteboard: [nsbeta2+] → [nsbeta2-]
doh, wrong defect.  Dave needs sleep badly.

nominate for beta3. If it doesn't go away by beta 3 it never will, and that would 
be bad. Note that we also now have another dir, psmdata, polluting the 
application directory. These must be cleaned up!
Keywords: nsbeta3
I thought we nsbeta3+'d this a long time ago.
Whiteboard: [nsbeta2-] → [nsbeta3+][nsbeta2-]
Unfortunately, this is a P3 priority and PDT was looking at P1-P2 bugs to mark
nsbeta3++ or not.

If this really needs to get into nsbeta3, I'd suggest emailing PDT.   Thanks!

we need this for RTM.
Keywords: rtm
Are we just trying to get rid of obsolete files?  I don't think we need to get 
rid of the directory itself.  The HTML implementation files should not be moved 
into chrome.  They aren't chrome, they have nothing to do with xul, and they 
don't belong in a jar (since I could see embedding folks cutting out the JAR 
protocol for space).

Then we need a better place for non-chrome resource files; there is some stuff in 
res, and in psmdata.

I object to having a folder called "res" in the application directory because Mac 
users will laugh and point at it, then throw it in the trash. It needs to be 
"Resources" or something. Ideally, on Mac, it would move under Essential Files.

I don't care if we move the core HTML files into some other directory with a 
better name.  I'm just making sure we don't throw a bunch of files into chrome 
that we shouldn't.  :)
Arguably, "res" (or "resources") is a generalization of "chrome". Maybe we 
should put the chrome jars under res (although actually, I think this is 
unimportant). Nonetheless, the things in res (including psm stuff) should get 
packaged into some jar. Right now, necko is in the comm.jar file. I don't see 
why other subsystems should be different.
Not holding PR3 for this. Marking nsbeta3-
Whiteboard: [nsbeta3+][nsbeta2-] → [nsbeta3-][nsbeta2-]
*** Bug 54445 has been marked as a duplicate of this bug. ***
OS: Mac System 8.5 → All
adjust summary. dprice, any progress on this?
Summary: res directory needs to go away → Need to remove debug and test files from the res directory
I'm working on finding good homes for some of the files.  The .properties files
concern me at the moment because I think they belong in a locale jar.  If they
are res, they aren't being localized.
Also there are considerably more files installed in the res directory for
mozilla than are installed for netscape.

When you say "installed... for mozilla" do you mean you actually used the 
mozilla installer, or did you just unpack the nightly zipfile? The zipfile 
contains whatever the build happens to produce including test files and old 
cruft. From what I can see the res directory in a Commercial installed build 
has exactly what's in a mozilla /installed/ build plus two more files.
I disagree with this bug.  We should not be moving required files into the
chrome directory or worse inside a jar file.  bits that are required for basic
html layout should not require chrome (and RDF).  We have customers that was
smaller footprint.  we want to be able to strip out chrome and RDF if the
customer wants just html layout without the hassle of moving files from chrome
into res.



I agree with Doug.  Basic files required by HTML (that doesn't use chrome to 
perform localization) should be loose in their own directory (as they are now). 
I was relying on this as well, since I need to move some more files out of 
chrome that don't belong there.

I have to disagree with you guys. My vision is that every Component consists of 
a dll and a jar file for its resources. The contents of these jar files may get 
combined into an uber-jar for a particular shipping product (like we do with 
comm.jar now), but there shouldn't be random odds and ends scattered around the 
bin directory.

Are you worried about the need to include the jar protocol code and zip 
library? I think that's pretty minimal. And access time is better than flat 
files, so that can't be the issue.
warren, you sounded like the boss in office space! ;)

"Ummm, yeeeeaaah.  I think I'm going to have to go ahead and *disagree* with you 
there."

warren,
I like this conceptually.  The problem that I have is that if you drop something
into the chrome directory structure, in terms of footprint, it is very heavy.
In order to use chrome:// you need around 700k of stuff :

-rwx------    1 dougt    dougt        107k Oct 17 08:41 libchrome.so
-rwx------    1 dougt    dougt         44k Oct 17 08:41 libjar50.so
-rwx------    1 dougt    dougt        552k Oct 17 08:41 librdf.so

(numbers from a netscape 6 optimized build from a few days ago)

Maybe we should just rewrite chrome so that it does not depend of RDF (David, is
this absurd?), but until then adding this much bloat for something the file
system provides (file access) is not a good thing for embedding.

--doug


Is this rdf number that big because it still contains xul elements, etc.? If so, 
we're going to take that out, right? I don't know why the chrome registry is so 
big.

What about the zlib dll? I assume you still need that for xpt files, right?

So what does the boss from office space sound like?
We're cutting chrome for embedding.  We don't need it at all unless we're 
using XUL.  Don't stress over it.

yes, that rdf number includes XUL.  Waterson or Hyatt would know the rough
estimates of what percent is xul in that rdf xul.  I remember something like
75/25 but do not remember which is which right now.

zlib, at least on my system is part of the dist (installed in /lib or /usr/lib).
 I am not sure if mobile linux includes zlib or not, but in either case it is
quite small. I think mozilla's zlib is something like 35 or so k.

So, I guess what I am arguing for is that we wait until we can minimize the
footprint needed to support chrome urls before adding more required files there.
Yeah, but what about the other core files that are currently in jars? Necko and 
xpcom string bundles, for instance.
have they already moved into chrome/jar paths?
rtm-, this does not appear to be an rtm bug.
Whiteboard: [nsbeta3-][nsbeta2-] → [nsbeta3-][nsbeta2-][rtm-]
I think if there is some idea that we could get 
a performance or other big gain out of doing this
if might sound worthwhile.  until we see  the big
advantage moving this to the back burner.
Target Milestone: --- → Future
the big advantage is that we no longer look like idiots for shipping all these 
files. maybe that's no big deal on win32, but it is on mac.
Keywords: nsbeta2, nsbeta3, rtm
Whiteboard: [nsbeta3-][nsbeta2-][rtm-]
We're still shipping 500k of crap in res/samples (on Mac at least). Why?
Assignee: dprice → seawood
Component: Browser-General → Build Config
Priority: P3 → P2
QA Contact: doron → granrose
Target Milestone: Future → ---
I think we can remove all of res/samples, res/rdf, and res/throbber.
I think the right thing to do here is to make Mac OS X run the stuff in
xpinstall/packager. We'd probably want to use pkgcp.pl to copy from
dist/Mozilla{Debug}.app to the target, using a new packages-macho.

Even if we do this, we'll still get res/samples etc, which we don't seem to
strip out, even for milestone builds. But at least we can fix that XP then.
I fail to see why this is considered a Build Config issue.  If the files under
res/ are unneeded, then tell the component owners to stop dumping their crap
there by default.  Making OSX use packages-mac is a separate issue IMO and
doesn't address the actual problem here.  Tarball builds will still have this cruft.
Assignee: seawood → sfraser
Bug 203106 filed on getting Mac OS X to do packaging stuff. Reassiging this bug
to layout, who own most of the res/samples and res/throbber crap.
Assignee: sfraser → other
Component: Build Config → Layout
QA Contact: granrose → ian
Target Milestone: --- → Future
There is still a lot of unneeded stuff in /res, and some of the 'needed' stuff
can problably moved to chrome://...
Assignee: layout → nobody
QA Contact: ian → layout
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.