On 12/20/2012 09:53 PM, David M
Williams wrote:
Normally "having two
versions"
wouldn't hurt anything, unless you know there's some API change
or something
that makes them incompatible
Requiring 2 different versions of a feature which contain some
"singleton" bundles (ie that define some extensions or extension
points) makes that the 2 projects requiring the feature don't work
together.
Ie if site includes Dali (which includes EclipseLink x.y.z) and
EclipseLink x.y.z+1 and if EclipseLink contains a singleton bundle,
it will be most likely impossible to install Dali and EclipseLink
x.y.z+1 in the same Eclipse.
The inclusion in feature is a really strong coupling. Version is
statically chosen at build-time. This is a bad idea if you are
project X to "include" a feature from project Y since you lock
yourself and your users' application to the version of Y you decided
to include. It's generally a workaround for not requiring users to
add multiple sites. Instead, you should:
* use "require" which allows some version range for feature you want
to depend on, and
* you could ship a copy of the feature of Y you depend on along with
features for X in the repository you produce for X.
With this, you remove some constraints and one can update version of
your dependencies. The fact that the dependency features are
provided on the site makes that installation won't require
additional sites.
@David: maybe we should set up a rule to verify that as part of
Simultaneous Release, since these "locking because of inclusions" is
a common reason why some installations/updates fail.
|