Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Notes from a Heretic: Why do we have the Ganymede update site?

I swear I didn't bribe Michael to write this as an advertisement for Ganymede M7... some responses below.

Michael Scharf wrote on 04/28/2008 08:45:34 PM:

> - Plugins and features coming from one update site
>    are often related, therefore, the update sites should
>    be represented in the update manager views as roots of the
>    feature tree.

This is done in platform M7. You can categorize available software by site, by category, or by name using the drop down menu in the "Available Software" tab.

> - There should be super-update sites: update sites that represent
>    a set of update sites (instead of having either on update site
>    for all or let users find the update site (exercise: use google
>    and try to find the CDT update site)).

This is available in classic update sites as well as p2 repositories. UM had a notion of "associate sites" that allowed you to link together multiple sites. p2 has a similar concept of repositories being able to contain references to other metadata or artifact repositories.

> - Features are *technical* associations of plugins. Users need
>    representation of what they want (something that fits to the user
>    mental model). The packaging project shows quite nicely how this
>    works. We have had a similar discrepancy between eclipse
>    release numbers and the technical versions of plugins. Until
>    eclipse 3.2, all plugins got the release version number
>    What is missing is a distinction of *user* features versus
>    *technical* features. Some features make no sense to be installed
>    on their own. Those are purely technical features. The packaging
>    project is closer to *user* features but I think that the update
>    manager should provide something at this level.

Platform 3.4 M7 with p2 is moving in this direction. You'll notice in M7 that the term "feature" has been dropped from the update UI, since p2 has no inherent notion of features. You can represent features using p2 constructs, but you can equally create "user features" -  groups of logically related content that bring together plug-ins from various sources. Since p2 separates metadata from the actual artifacts (plugin jars, etc), you can introduce your own metadata repository that provides a completely different collection of user-oriented offerings, backed by the same artifact repository containing the actual plugins. We won't be able to fully exploit this power in Ganymede, but we are moving in the direction of not enforcing the provider's packaging semantics (features) on all users.

I hope in a future release, a cross-project team like the packaging project will publish an metadata repository that provides a meaningful grouping and organization of software that makes sense to regular end users, and this would provide a user-friendly face on the simultaneous release. Other people could create competing or complementatory metadata repositories that focus on different areas, like a modelling metadata repository that provides groupings and categories that make sense to the modelling community. Each project could then build and maintain their own artifact repository containing the contents of their contribution to the simultaneous release, without exposing their technically-oriented feature structure on hapless users that don't know how to navigate the daunting Eclipse acronym soup you mention.

>    I should only see the features I have installed and the implicit
>    dependencies should be marked as implicit and when I uninstall
>    a explicitly installed feature, the implicitly installed features
>    should disappear.

This is done in platform M7. If you install a feature that contains or requires 10 other features, you will only see the one feature you personally installed in the "installed software" tab. If you uninstall something, any implicitly installed features that are no longer required by any of the roots are removed.

> - And features themselves should have a "tag" if they are user
>    features or automatically installable features. In fact, I think
>    features should only be there to allow the user to choose "roots"
>    that are not picked up by automatic plugin dependency analysis...

Although it's not evident today, the UI in platform M7 works this way.  The "available software" tab only shows installable units that have a special "group" marker tag. You can add a feature to a repository without having this tag, and it won't appear to the user. Of course, which features make sense as "roots" is in the eye of the beholder. I'm sure each project thinks each of their features is important and worthy of displaying to the end user. In the context of a larger release train, the set of "roots" needs to be pared down to a more reasonable size. Again, I think with p2 we have the basic infrastructure in place to do all this, but we're running out of time to really exploit these features in the Ganymede release.


Back to the top