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

[alvaro sanchez <alvsan09@xxxxxxxxx>]

Steffen,
Thanks for the detailed explanation.
I am experimenting with the specifics of R4E and will come back with a
proposal in Bug 347482

I would really like to see some Mylyn feature.xml as additional
examples, It seems I am missing a reference since I don't see all of
them from the Mylyn commons, Mylyn Builds, repositories.

One more question, The SDK features are making reference to source
bundles, how is mylyn generating them  ?

As for making R4E independent of the version control system
connectors. It's true that we should not force loading of any specific
connector, however, R4E offers fairly limited functionality unless
it's used in conjunction with a version control system. I have not
seen a functionality where the user is forced to pick at least one
feature from a list. I guess one possibility would be to warn the user
with a pop-up when using e.g one of the R4E views "No version control
system connectors are installed and R4E is working with minimal
functionality"

/Alvaro



On Mon, May 30, 2011 at 2:57 PM, Steffen Pingel
<steffen.pingel@xxxxxxxxxxx> wrote:
> 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
> _______________________________________________
> mylyn-reviews-dev mailing list
> mylyn-reviews-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylyn-reviews-dev
>