I guess this question comes down to
whether we expect the EPP packages to satisfy the vast majority of users.
Packages are like the table d'hoteat a restaurant, whereas the Ganymede
update site is like ordering a la carte. Many users will be satisfied
with the packages, but other more discerning users want greater flexibility
to pick and choose among the available offerings.
I think ordering a la carte would be
very difficult without the common update site. You need to know what
Eclipse project contains the software you want, the location of its update
site, and the version of that software that is compatible with the platform
version you are running (many projects have a different site for different
streams). Then, you need to figure out the cross-project prerequisites
of the software, and repeat the process for each of their update sites.
I believe this would be quite a complicated even for Eclipse experts to
The common site also gives us a good
control point for staging and running tools such as site optimizers and
the EPP packaging scripts. For example we would like to run a script over
the Ganymede site in 3.4 to inject p2 metadata into it, which optimizes
performance for users of the latest Eclipse platform release. Without a
common site, each project would have to run such tools independently. Also,
it gives one site for our mirrors to replicate that covers all the simultaneous
Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
04/28/2008 01:39 PM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
If we have packages, why have a separate update site?
The packages have all the update sites built in (via the feature.xmls).
And if someone wants to add new functionality to their
existing Eclipse, they will go to the project specific update site and
get the latest bits.
For adopters, we have the project downloads and update
sites - why should we have a second update site for these?
In fact, having a second update site just makes things
more complicated because then "where do I get future updates? do I
get them from the central update site or from the project update site?
and why are there so many similar update sites listed in my Eclipse?"
More complicated for project teams too, because then they
have to maintain different site.xmls, feature.xmls, etc.
original reason for the unified update site was because it was confusing
for users to have to go here and go there and go the other place to put
together a package. But now that we have packages, why do we need the unified
update site? It seems to be extra hassle and complexity for everyone at
no net benefit to anyone.
[end of message] _______________________________________________
cross-project-issues-dev mailing list