[pde-build-dev] The "3.2 Way": Feature/Plugin Dependency Confusion

[Mark_Melvin@xxxxxxxx]

Hi There,

I am moving the build of our product
over to Eclipse 3.2.  While I am at it I am overhauling the feature
structure, and I thought would move to the new way of plugin versioning
as well.  Three major changes to our build due by Friday - what could
possibly go wrong? ;o)

I must admit however, I am a little
confused with the recommended way of declaring dependencies between features
(plugins?) as recommended in this document:

http://www.eclipse.org/equinox/documents/plugin-versioning.html

In particular, under Versioning Features
it says:

To avoid the brittleness caused by version changes in
required features, we recommend feature authors favor the _expression_ of
their dependencies at the plug-in level, rather than at the feature level.
To be more precise, all the immediate plug-ins required by the plug-ins
included in a feature should be listed as plug-in prerequisite of the feature.
This approach has the benefit of isolating feature authors from changes
that do not impact them. 

However, when I look at the plugins and features in Eclipse 3.2 RC7, I
do not see this implemented, unless I am not understanding this paragraph
correctly.  If I look at the JDT feature for instance, it only declares
the following "requires":

   <requires>
      <import plugin="org.eclipse.platform"
version="3.1.0" match="compatible"/>
   </requires>

What?  Only require the org.eclipse.platform
**plugin**?  It might make sense if it was requiring the *feature*,
but...  OK, so I check the PDE feature and it does something similar:

   <requires>
      <import plugin="org.eclipse.jdt"
version="3.0.0" match="compatible"/>
      <import plugin="org.eclipse.platform"
version="3.0.0" match="compatible"/>
   </requires>

What the heck is going on here?  Why
are these features only requiring basically what amounts to "branding"
plugins?  I can see that all of the declaration of versions matching
is actually done in each plugin explicitly on all of its dependencies,
but what are these features trying to accomplish with these requires clauses??

Thanks,
Mark.
AMI Semiconductor - "Silicon Solutions for the Real World"
NOTICE: 
This electronic message contains information that may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.