304545 - Shrink download size by stripping licenses during build process

Status: RESOLVED WONTFIX

(Calendar :: Build Config, enhancement)

Description

[Joey Minta]

Inspired by bug 279698.

Based on that bug, it's acceptable to strip licenses when packaging files into a
.jar.  This can be done by using pre-processor comments, rather than js comments
for the license block.

Every .js file in calendar.jar or sunbird.jar would need to be changed with the
exceptions of:
resources/content/pref/nsPrefWindow.js
resources/content/pref/wsm.js (no license)
sunbird/base/content/pref/connectionPrefs.js

Question:
Can we do this for .xul too?

Comment 1

[gekacheka]

My understanding is that neither really would accomplish much savings for the
download file, which is what matters most to most users.

Currently the calendar.jar file is created without individually compressing the
files inside it, and the entire jar file is compressed as as a whole inside the
install files (.exe or .zip for windows).   In theory this effectively means
space for just one copy of the license text is shared among all the files inside
the calendar.jar (once it is compressed inside the .exe, .zip, or .tgz).

For files that are not inside calendar.jar (mostly installed to
sunbird/components/):
  In the .zip/.tgz file for nightlies it could save some space.
  In the .exe file, maybe the sunbird/components/ directory could be combined
into a jar that is compressed as a whole, not individually, then expanded when
it is installed. 
  

An important disadvantage of removing the license text is that the line numbers
in javascript errors will be different if the license has been removed.  It
makes it harder for people to track problems if the line numbers don't
correspond to the line numbers in cvs or lxr.

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

I think that this change will produce more problems then it solves. The line
numbers may not match anymore.
There are other places where more size reduction can be gained, like in libical.
So for now, this is wontfix. It might be fixed around 1.0 or something, when
downloadsize becomes a concern.

Comment 3

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 4

[Simon Paquet [:sipaq]]

Daniel, is this something we might want to consider or is this WONTFIX?

Comment 5

[Daniel Boelzle [:dbo]]

Yes, I think this is WONTFIX for the mentioned reasons.