Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Check your feature includes in Helios

For reasons I don't understand, I'm not able to post to (or even subscribe to) the AC mailing list (likely a discussion for another day).  Maybe someone on the AC can forward this to that list for me.

I wrote a small tool to scan the Helios repository for feature IUs that appear "tampered".  In particular, I grabbed all the feature.xml files from Helios and looked at what they "included". I then looked at the actual features IUs in the Helios repo.  If someone listed a plug-in as "included" in their feature.xml, but their version ranges were not strict, I simply flagged the IU.

Looking through the output, 4 projects jump out:
EMF
XSD (I think this is part of EMF)
buckminster
ECF**

** I understand ECF is consumed by the platform in a strange way, so this one might be expected. I'm not sure.

I can send the complete list of features if anybody is interested.  I can also make the tool available if we want to use it as a sanity check.

Cheers,
Ian

On Mon, May 31, 2010 at 11:39 AM, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx> wrote:
If you contribute features to Helios then please read and consider this.

Recently there has been a discussion[0] on the PDE mailing list about the "slackening" of feature *includes* dependencies. A brief summary:

Features can include and require things.  When you include something you end up with a tight binding to a particular version. When you require something you can spec a range of acceptable versions.  Features were specified this way to ensure that installing a particular feature version would unambiguously and repeatably result in the exact same *included* features and plugins being installed.

There seems to be a few projects in Helios that are slackening this characteristic and using various means to create p2 metadata that has imprecise ranges for *included* elements. The net effect is that once consumers have multiple versions of prerequisite bundles available (e.g., once Helios SR1 ships, some other repo is added to a user's context, ...) installing these tweaked features will give ambiguous results and will not be repeatable.

While it is accepted that tight bindings can be challenging and p2 has much more underlying power and there are many interesting usecases, this is a departure from a long standing API and consumer understanding. Consumers creating and shipping products based on the features we distribute in Helios will fully expect the exact version specifications on their included components be used at provisioning time. Changing includes to use ranges breaks the API contract and should not be allowed in the repo.

Accordingly, we should all ensure that the p2 metadata correctly match the expressed intent in the authored features. Particularly WRT version and version range specifications.  This would actually be a useful repo sanity check.

Jeff

[0] http://dev.eclipse.org/mhonarc/lists/pde-dev/msg01804.html





_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource

Back to the top