|RE: [eclipse.org-planning-council] RE: [cross-project-issues-dev]Heresy mark II (summaries and replies)|
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 pre-populating information
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 GETTING AN
Because of this, those project update sites typically
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 the categorization,
since categorization will be strictly per-project only. Therefore:
-1 for removing the Ganymede site
+1 for investigating turning Ganymede into a P2 Metadata Repository
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 assembled pointers
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 gigabyte
range of diskspace on both download.eclipse.org and all the mirrors.
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 P2 because
it does automatica mirror selection anyways.
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
Back to the top