Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 75285

Summary: Compute download-size and install-size for feature.xml
Product: [Eclipse Project] PDE Reporter: Nick Edgar <n.a.edgar>
Component: BuildAssignee: pde-build-inbox <pde-build-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: aniefer, birsan, caniszczyk, contact, digulla, elias, gunnar, mober.at+eclipse, pascal, phil.kursawe, pombredanne, pyvesdev, robbinsj, sonia_dimitrov
Version: 3.0Keywords: helpwanted
Target Milestone: ---   
Hardware: PC   
OS: Windows 2000   
Whiteboard:
Bug Depends on:    
Bug Blocks: 131802    

Description Nick Edgar CLA 2004-09-29 10:22:01 EDT
R3.0

- installed 3.0
- went to upgrade to 3.0.1 using update manager
- it indicated:
Required space: Unknown
Free space was 25708800KB

While I'm almost certain 25G will be enough space, it would be nice if the
required space was indicated <g>.
Would also be good to express the space in MB or GB when appropriate.
Comment 1 Nick Edgar CLA 2004-09-29 10:24:04 EDT
It also complained that the update wasn't digitally signed.
Not a problem for me, since I trust eclipse.org <g>, but it would be nice to
avoid this hiccup too.
Comment 2 Dorian Birsan CLA 2004-09-29 11:05:51 EDT
Sonia, is it possible to build the features so that the size of plugins is 
computed and set inside feature.xml?

As for signing, I remember there is some support in pde to do this as well.
Comment 3 Dorian Birsan CLA 2004-11-22 15:51:15 EST
Moving to PDE Build for investigation.
Comment 4 Pascal Rapicault CLA 2005-03-14 13:45:49 EST
*** Bug 44638 has been marked as a duplicate of this bug. ***
Comment 5 Pascal Rapicault CLA 2007-03-30 09:48:27 EDT
*** Bug 65787 has been marked as a duplicate of this bug. ***
Comment 6 Pascal Rapicault CLA 2007-03-30 09:48:31 EDT
*** Bug 149364 has been marked as a duplicate of this bug. ***
Comment 7 Wassim Melhem CLA 2007-05-07 00:34:53 EDT
*** Bug 185659 has been marked as a duplicate of this bug. ***
Comment 8 Chris Aniszczyk CLA 2007-07-26 12:15:05 EDT
Phillipe, do you have code that you're willing to contribute for this one? You mentioned something in a previous bug report. I'd like to see this available out of box in 3.4
Comment 9 Philippe Ombredanne CLA 2007-07-26 12:34:46 EDT
(In reply to comment #8)
> Phillipe, do you have code that you're willing to contribute for this one? You
> mentioned something in a previous bug report. I'd like to see this available
> out of box in 3.4

Chris: I dove some code which does that . I'll give pointer to it next week.
i would be happy to contribute!
Comment 10 Chris Aniszczyk CLA 2007-07-26 12:37:32 EDT
setting target to 3.4M1 as a reminder
Comment 11 Benjamin Cabé CLA 2007-09-28 14:38:48 EDT
Hi,

I would be happy to test and/or evaluate your code if you post it, Philippe, as I think it would be really great to include it in 3.4 ASAP ! :)
Comment 12 Benjamin Cabé CLA 2007-10-12 06:04:05 EDT
Hey, is there anybody out there ? ;-)
Philippe, is your code running OK againt 3.4M2 ? Would you want me to test it before integration ?

Regards
Comment 13 Chris Aniszczyk CLA 2007-11-02 12:08:29 EDT
Hey Phillppe, this would be a nice addition for 3.4
Comment 14 Andrew Niefer CLA 2007-11-02 13:46:44 EDT
Note that for Ganymede, this significantly more complicated than simply setting download sizes in the feature.xml at build time.

Signing jars modifies their sizes, and the feature.xml files can not be modified after signing.

To get plugin sizes, plugins would need to be signed separately from features, the features then updated later with the plugin sizes.

To get feature sizes, features would need to be signed in depth first order of inclusion, so that the containing features could be updated before being signed.
Comment 15 Pascal Rapicault CLA 2007-11-02 17:20:56 EDT
Also we are hoping that Ganymede will be delivered using p2 where this problem is handled.
Comment 16 Martin Oberhuber CLA 2007-11-05 09:04:55 EST
Comment #9 mentions some code for this feature - is it available?
Since 3.4M1 is over already, could a proper target milestone be found?

Regarding comment #14 (change in size due to signing), I see two options:

  a) Ignore that change since it is relatively small and the sizes are
     given in KByte measure only anyways so they are not 100% accurate

  b) Perform a two-stage bootstrapping approach: Have build #n create an
     output file that lists each plugin and feature with the size of the
     signed (for install size) / signed+packed (for download size) size.
     Have that output file stored in a well-known place or checked in.
     Have build #(n+1) read this file and apply the sizes to the plugins
     and features.
Comment 17 Andrew Niefer CLA 2007-11-05 14:52:01 EST
(In reply to comment #16)
>   a) Ignore that change since it is relatively small and the sizes are
>      given in KByte measure only anyways so they are not 100% accurate

I am in favor of treating these sizes as approximations only.  (I did not realize they were written in KB in the feature).

Doing this the only signing we have to worry about is the JNLP signing that occurs in the build proper, and not the signing that occurs outside of pde.build.

Are sizes only specified on included plugins?  If they are not specified on imported features then this also simplifies things.
Comment 18 Lars Vogel CLA 2018-11-13 07:27:25 EST
Mass change for PDE Build bugs tagged with "helpwanted". PDE build is not actively enhanced, hence I close these bugs as wontfix. Please reopen if you want to contribute a patch.