Re: [cross-project-issues-dev] Notes from a Heretic: Why do we have the

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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
>      http://www.eclipse.org/equinox/documents/plugin-versioning.html
>    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 eclipse.org 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. 

John