|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:EMFXSD (I think this is part of EMF)buckminsterECF**** 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.cross-project-issues-dev mailing list
Recently there has been a discussion 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.
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource
cross-project-issues-dev mailing list
Back to the top