[jbosstools-issues] [JBoss JIRA] (JBDS-2649) Installer shouldn't contain Google Eclipse features/plugins

[ https://issues.jboss.org/browse/JBDS-2649?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBDS-2649: ---------------------------------- [~mickael_istria] The installer has not changed size, it's the same as before because as you said, it filters out the redundant .pack.gz files. [~maxandersen] The update site zip ought to be smaller because the extra 40% disk usage from including both pack200'd and normal jars is not needed for an offline zip. HOWEVER... if the goal is that the zip === the update site, then we need to accept that the zip will be 40% bigger and MUST include everything that's on the unpacked site. If however we want that the zip contains only regular jars, whereas the unpacked update site contains BOTH pack200'd and regular jars, then we essentially have *THREE DIFFERENT* offerings: a) installer jar (includes JBDS/JBD + enough TP to make it installable, izpack stuff, optionally EAP, but no pack200) b) unpacked update site (folder that includes just JBDS/JBT content, with as little 3rd party stuff as possible; includes pack200 jars + regular jars) c) archived update site (zip that includes just JBDS/JBT content, with as little 3rd party stuff as possible; only regular jars; pack200 jars are removed and metadata is regen'd) It is unlikely (though possible) that installation from (b) and (c) might happen differently. Thus QE / automated tests would need to cover both scenarios. OTOH, if we retain the pack200 jars in the update site zip, then we have only *TWO DIFFERENT* offerings: a) installer jar (includes JBDS/JBD + enough TP to make it installable, izpack stuff, optionally EAP, but no pack200) b) unpacked update site (folder that includes just JBDS/JBT content, with as little 3rd party stuff as possible; includes pack200 jars + regular jars) c) archived update site (zipped up identical copy of (c)) I see merits in both approaches, but IMHO the better answer from a QE/test/support perspective is that (b) and (c) both contain the exact same pack200 + regular jars & no metadata regeneration is needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira