Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cross-project-issues-dev] Re: Notes from a Heretic: Why do we have the Ganymede update site?
+1 for keeping the site, and the EPP packages that depend on it for their input.
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). 

Nick


    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