RE: [eclipse-dev] Combo packages proposal

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Through the wonders of PDE build we
could indeed create additional packagings quite easily.  However,


- We'd have to define this new "uber-package".
 A list has been suggested but it was missing Hyades, and a few others.
 Why not put them in?  And why not some popular ones from outside
Eclipse?
- We'd need a mechanism for the constituent
components to declare what they want to contribute to the uber-package.
 The components all build on their own schedule.
- Whip up some build directives and
away we go
- We'd need 1+GB more disk space *per
build* (on our server plus the mirrors)
- Update the download pages to have
an additional list of items
- Buy more bandwidth to account for
all the people who fetch the uber-package of N additional things when they
really only needed 2 or 3 of them but hey, it was just easier to get the
massive wad than go to some additional sites.

Certainly possible but not particularly
tasty.  Note also that the content of the uber-package would never
have been tested since it is part of the build and by definition the things
that are added in are added to an Eclipse that was just built.

A very do-able interrim solution is
to push the providers of the various add-on components you mention to simplify
their download pages and clearly call out the download you should get.
 They should (if there is demand) also provide the unified "SDK"
style zip.  This should simplify things considerably for people wanting
individual compoents as well as collections of components.

Again, I believe we are all sympathetic
to this issue but mix in the things you want with the pressures from RCP
carvings of the world and it is clear we need a solution but that additional
packagings are not the way to go.  

Jeff

p.s., BTW, we provide the runtime and
SDK downloads so that people building/shipping products can clearly distinguish
between what they should get for development vs. what they should use for
deployment/delivery.

"Ed Burnette" <Ed.Burnette@xxxxxxx>
Sent by: eclipse-dev-admin@xxxxxxxxxxx

02/12/2004 03:43 PM

Please respond to
eclipse-dev

To	<eclipse-dev@xxxxxxxxxxx>
cc
Subject	RE: [eclipse-dev] Combo packages proposal

I'm not against the update site idea or the dynamic
zip idea - by all means investigate that. Meanwhile though, doing one or
two combo packages as part of the automated builds would be a low-tech
way to solve the problem. There is already a precedent: you have the Platform
Runtime binary, the JDT Runtime binary, and the Eclipse SDK binary which
combines them both (+PDE).

Jeff McAffer wrote: 
> For every person that asks for the combo pack, there
> is some one complaining that the SDK is too big.

You're not going to make everybody happy but you can leave the SDK and
the existing packages the way they are and make this an additional option.

> Combo packs do not scale...

Might be better than umpteen separate downloads per user, and redownloads
when they get the wrong version?

> and they IMHO are fundamentally at odds with the component model
> put forward by Eclipse (i.e., why should Eclipse get to ship a
> huge wad when we tell everyone else to use components, update sites,
...) 

I agree. But until there's a better way available, this could be useful.

Ed Burnette wrote:
> Instead of 8 downloads, the user would just have one.

Actually I just did it, and for my list of components (not counting Web
tools) it was 13 downloads because of some components having separate source,
doc, and binary zips. I just got the latest integration build of everything
but I'm not sure it will all work together. It's going to take a while
to unpack everything into the right place and find out.
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
http://dev.eclipse.org/mailman/listinfo/eclipse-dev