I think I see the point in your theory, that copying bits
from location x1, x2, x3...
to location G (for ganymede) should be equivalent to
about location x1, x2, x3, ... in the base Eclipse
downloads (SDK, packages).
In the case of Ganymede, however, we're not only copying
but also filtering:
the project update sites x1, x2, x3... are typically
organized in a different way
than Ganymede, because their job is UPDATING rather than
Because of this, those project update sites
Carry multiple versions of the project (making it very confusing for
Contain more small add-ons like Ganymede (which are not considered
Mainstream, and thus only confuse
So, while I'm not totally opposed to your theory, my word
of caution is that
if we want to go this route, projects will likely need to
have two site.xml
themselves -- one for their main update site, the other for
"initial install via
Which is, essentially, same work as before (maintaining
site.xml and site.sc).
And, deprives us of the ability to do more fine-tuning with
since categorization will be strictly per-project only.
-1 for removing the Ganymede
+1 for investigating turning Ganymede into a P2
rather than holding all
the verbatim bits
I'm in favor of investigating using more P2 features for
the Ganymede site
instead. Perhaps there are possibilities of making the
Ganymede site more
of a "metadata Repository" only, that contains the
to the project update sites only but not the real files.
This would relieve
us from actually copying any bits, and would save us in the
range of diskspace on both download.eclipse.org and all the
Provided that mirror are set up for mirroring all the
project update sites,
and not just Ganymede alone. But even this can be solved by
it does automatica mirror selection
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
I was under the impression that we already did pre-populate with
more than one site. To test my theory, I downloaded the Europa package
"Eclipse IDE for Java Developers" and opened Help > Software Updates >
Find and Install... > Search for new features and, voila!, there are nine
update sites pre-populated.
We could very easily pre-populate with all
the project's update sites, n'est pas? And that would provide a natural
additional level of classification of the features...
I'm sure we could prepopulate more then one