Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Status and outlook for Kepler M4 +3

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.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets

Back to the top