Hi, Marc,
More comments in-line, below.
Cheers,
Christian
On 27/07/10 10:19 AM, Marc Khouzam wrote:
Thanks for the info. If I
understand correctly, your suggestion is to require the latest version
of the plugins.
I think that makes sense and
that we have been making that assumption in CDT without enforcing it.
I dont' believe anyone expexts
to have a feature of CDT 7.0 use a plugin of CDT 6.0
... or expects a feature of CDT 7.0 to work with Eclipse 3.5.x, for
example?
So,
looking at the Dependencies editor of feature.xml, I can see that we
can choose between:
Equivalent
Compatible
Greater or Equal
Perfect
<none> (no version
specificed)
There is also a check box
labeled "Recompute when feature plug-ins change"
but I couldn't figure out what
it actually does and when.
Yeah, I've never tried that, myself. Sounds just a little too
trusting, plus I don't know how the re-calculation is actually
triggered (zx would know, if he's listening).
My first thought is that we
should do one of two things:
1- Use "Perfect", which I assume
means we require one specific version of the plugin.
This will require us to change
the version in the feature at the same time as when we change
it in the plugin. We can detect
errors quickly as soon as someone try to install a build.
But, this conflicts with the bundle-to-bundle dependencies, which
aren't perfect matches. And it would prevent updating the dependent
bundles for bug fixes (micro version).
2-
Don't specify a version at all in the dependency. This requires less
work on our part
(no need to maintain versions in
feature.xml) but then the feature will accept to be installed
with any version of the required
plugin. At first glance, this does not seem too bad, since
we kind of were doing that
already in CDT (not really paying attention to the versions
in feature.xml)
Honestly, I don't know what is the value of the dependency version
constraints in the feature.xml any more, considering that bundles have
their own dependency specifications and p2 enforces them, anyways. The
feature metadata seems redundant.
If
we want to go with #2, we could clean up all the feature.xml files to
remove all versions
in the dependencies.
Makes sense to me, but I'm not a CDT committer, and this goes a bit
beyond my experience.
Finally,
I assume that having a dependency on the same plugin twice but with two
versions is a mistake. In
platform-feature/feature.xml I see, for example:
<import
plugin="org.eclipse.cdt.core" version="5.0.0" match="compatible"/>
<import
plugin="org.eclipse.cdt.core" version="5.1.0"
match="greaterOrEqual"/>
<import plugin="org.eclipse.cdt.core" version="5.2.0"
match="compatible"/>
This is an artifact of the "Compute Dependencies" button. It doesn't
reconcile the different dependency ranges from different bundles in the
feature to the same dependencies. This is a bug in the PDE tooling (I
haven't checked Bugzilla, yet, to see whether it's been reported). I
think it's safe to pare this down to the highest required version
number with "compatible" match.
I guess we should clean that up
and replace with either
(#1) <import
plugin="org.eclipse.cdt.core" version="5.3.0" match="perfect"/>
or
(#2) <import
plugin="org.eclipse.cdt.core"/>
I vote for trying out #2.
What do people think?
Marc
--------8<--------
