Re: [mylyn-dev] [mylyn-reviews-dev] Releng + Orbit + Features

[Steffen Pingel <steffen.pingel@xxxxxxxxxxx>]

Hi,

thanks for raising that. Unfortunately I don't know any good source
for best practices in regard to managing feature dependencies. We have
gone through several iterations of releng tools and feature structure
in Mylyn and I can share the things we have learned and give you a
recommendation for R4E based on our current policy.

First off, p2 will generally do a very good job in identifying
dependencies of items that are selected for install. Unlike the old
update manager which only took features into account p2 metadata
contains information about all artifacts down to the bundle and will
ensure that all pre-requisites whether specified through
Require-Bundle or Import-Package are satisfied.

That said, it's still a good idea to specify dependencies on a feature
level and to list all dependent features (with the exception of Orbit
bundles). This makes it obvious to users what the dependencies are in
the install process and enables p2 to update dependencies properly
later. It also avoids a situation where users end up with a half
working feature. An example of that is the Mylyn CDT bridge explictly
requiress the o.e.cdt.platform feature. If we solely relied on the
Require-Bundle headers in the o.e.m.cdt.ui bundle users would only get
an arbitrary subset of CDT plug-ins when installing the bridge instead
of a meaningful base CDT environment (they may need to install
additional features but at least they are not in a broken state).

Unless you are designing products I would recommend against using
feature includes and use require/import instead. The difference is
that include specifies an exact version, i.e. if you include CDT the
feature will only be compatible with one specific CDT version. Since
each version of Mylyn works across several Eclipse release train
versions it needs to be installable with a variety of downstream
versions and hence using exact version matches is not feasible. Still,
this leaves freedtom to downstream integrators like Tasktop who create
their own features that may have more strict requirements, e.g. for a
controlled RCP application where exact version matches are desired.

Orbit bundles are a special case since the Orbit project does not
provide features. Hence, all Orbit dependencies need to be included in
some feature otherwise Tycho (and other releng tools) will not include
the bundles when creating repositories. Sounds simple but there is a
pitfall. The Orbit project regularly releases updates. That means two
or more revisions of the same library bundle can exist and in many
cases it causes problems if users end up in a situation where they
have more than one version installed which can happen easily (e.g. bug
317392).

The fix for this is the same as for the features: use import/require
instead of include. This still leaves the problem that in order to get
bundles provisioned in a repository they need to be included in a
feature. We have either created dependency features not intended for
installation or (more recently) included them in the SDK but never in
the framework or connector features that the large majority of users
will install.

The current policy applied to R4E I would recommend the following:

R4E Feature
 * import feature org.eclipse.mylyn.versions
 * import bundle org.apache.commons.io
 * include plug-in org.eclipse.mylyn.reviews.r4e.core
 ...

Reviews SDK Feature
 * include feature org.eclipse.mylyn.reviews.r4e.feature
 * include feature org.eclipse.mylyn.versions.sdk
 * include plug-in org.apache.commons.io
 ...

Unless you have a direct dependency on the Git I would not specify a
dependency on EGit or the Versions Git Connector to not force EGit on
users who may only be using Subversion or CVS (same argument applies
to CDT, JDT etc. which could be decoupled from R4E through the Mylyn
Context framework). Sometimes it's more appropriate to use optional
plug-in dependencies instead of "bridge" bundles but that requires
great care since p2 resolves optional dependencies eagerly unless it's
instructed through a p2.inf file not to do so and users may end up
with more bundles than they wanted.

Hope that helps a bit. I would also recommend looking at Mylyn's
feature.xml files as examples.

Steffen


On Sat, May 28, 2011 at 5:24 PM, alvaro sanchez <alvsan09@xxxxxxxxx> wrote:
> Hello,
> I am looking for a  good source of information on Eclipse Release
> engineering.
>
> The situation is,
> if we have a set of features i.e. R4E + base features e.g. Mylyn
> Versions + Dependencies from Orbit plug-ins
>
> the resulting build of the R4E feature would include all the
> dependencies on the same generated update site as long as those
> dependencies are included in the feature itself.
>
> However including all dependencies in child features shall not be a norm as the
> dependencies are probably specified at higher level features as well.
>  I have seen a feature.sdk that includes e.g. orbit dependencies, but
> is there a guideline for it ?
>
> Can I simply include the dependencies from Orbit + dependent features
> i.e. Mylyn Versions and Mylyn git in my R4E feature ?
>
> The idea is to help users have a simple install and not hunt and
> gather individual dependencies one by one
>
> Any good references or examples are very appreciated
> /Alvaro
> _______________________________________________
> mylyn-reviews-dev mailing list
> mylyn-reviews-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylyn-reviews-dev
>



-- 
Steffen Pingel
Committer, http://eclipse.org/mylyn
Senior Developer, http://tasktop.com