|[eclipse.org-planning-council] Re: Notes from a Heretic: Why do we have the Ganymede update site?|
FWIW, I'm experimenting with my own non-Ganymatic, non-Buckminster approach to composite update site building (because we have projects with umpteen components, who all release their own updates independently, but share a site -- not that different from Ganymede, only smaller). If it goes well, I'll expand it to handle the whole of Modeling in one site (about as big as Callisto was), and then share it for other similarly organized projects (DSDP? WTP?), or even as a prototype for what might grow into an add-on to the existing Ganymatic.
One thing that Callisto/Europa/Ganymede has always done well, IMHO, is to provide a way to refactor individual projects' sites' features for better logical grouping on the composite site. Let's not forget the pain that that road was, and how much better we are for it, in terms of the end-user experience of finding logically related updates on one big site. (Will p2 finally solve the problem of only having one level of nesting in update sites? Here's hoping.)
As to the complexity & hassle of maintaining *.sc and site.xml files concurrently, for shame. Anyone who's not generating one from the other needs to try EMF, JET, or any other codegen tool you'd like. Creating an .sc file is a trivial exercise given a handful of attributes and a list of features, which can themselves be generated by unpacking your SDK zip and looking at the list of features therein. Want some sample code? Ping me, I'll share (it's all in CVS).
Let me open a can of worms and publicly ask why we have the Ganymede Update Site. It seems to me that: * For users, we have the Ganymede packages (http://phoenix.eclipse.org/packages/) <http://phoenix.eclipse.org/packages/%29> o If we have packages, why have a separate update site? The packages have all the update sites built in (via the feature.xmls). o 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. o * For adopters, we have the project downloads and update sites - why should we have a second update site for these? o 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?" o More complicated for project teams too, because then they have to maintain different site.xmls, feature.xmls, etc. The 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. Comments? Opinions? - Bjorn
Back to the top