[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Ganymede Must Do's (#13, #15)
|
It is strictly for estimating required size on disk for all the
features/plug-ins and compare it to the available size. Therefore estimate
is fine if the signing changes things only marginally.
Regards,
Dejan Glozic, Ph.D.
Manager, Eclipse Development 1A
D1/R0Q/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745 T/L 969-2745
Fax. 905 413-4850
Nick
Boldt/Toronto/IBM
@IBMCA To
Sent by: "Cross project issues"
cross-project-iss <cross-project-issues-dev@eclipse.o
ues-dev-bounces@e rg>
clipse.org cc
Subject
11/02/2007 02:07 Re: [cross-project-issues-dev]
PM Ganymede Must Do's (#13, #15)
Please respond to
Cross project
issues
<cross-project-is
sues-dev@eclipse.
org>
How fine-grained is the size information, and how much does signing
change the jar size? Also, does anything validate that the size listed
== the size downloaded, or is this just for estimating disk footprint
at install time?
If this is just to provide information, then I don't see the problem
if the values are only pre-signing estimates.
If this is to do actual validation to avoid installing a malicious
jar, then the value needs to be an accurate post-signing value. As
Andrew points out, this information would then need to be stored
outside the jar (or added during signing somehow?).
But if we store it outside the jars as information about the site's
features, these need to be aggregate numbers of feature + contained
feature(s) + contained plugin(s), or else add a lot of extra
information into the site.xml to effectively list all the
features/plugins and their individual sizes.
Once again, what's the purpose of this information? Providing
footprint estimate? Aggregate OK. Avoiding bad jars? Individual data
for each feature/plugin jar.
Then again... if the point here is to avoid bad jars... isn't that
what signing is for? Does the size matter at that point?
So... seems to me that ther are two reasonable solutions here:
a) generate an estimated pre-signing size and put that in feature.xml
b) generate a feature aggregate size when generating site.xml
$0.02,
Nick
On Nov 2, 2007 1:39 PM, Andrew Niefer <aniefer@xxxxxxxxxx> wrote:
>
> Getting download sizes into features will actually turn out to be rather
> difficult.
> Kim pointed out that the problem is that we are signing our jars. This
will
> change their size, and you can't go and modify the feature.xml after the
> feature has been signed.
>
> This means that plugins and features would need to be split into 2
groups,
> the plugins signed first, then the features modified with download sizes.
> And we won't be able to compute sizes for feature jars since they will
> change after signing.
>
> I don't know what the format of the site.xml is, but it would be much
easier
> to store download sizes there rather than in the feature.xml
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
