Hi Philippe,
Thanks for your advice. In general I agree with what you (and the
platform team) are saying. I do however think there is a subtle
difference between a "feature level dependency" and what we are trying
to accomplish. We don't want to express a dependency to an external
feature, we merely want to say that in order to use our feature, certain
runtime requirements must be met. We don't really care how the user
fixes that.
Our feature is insensitive to the version of the subclipse.core plug-in.
It works just fine with any 1.0.x and also with any 1.2.x. We don't want
to keep track of when new versions pop-up or what version a particular
user might have in his Eclipse installation. In essence, I'd like to
document the following for our SVN plugin:
"Buckminster Subversion support makes use of Subclipse from tigris.org.
In order to use it, you must first install Subclipse. If you plan to use
Buckminster in a headless environment, you only need to install the
Headless Subclipse feature. Buckminster will run just fine with any
version of Subclipse."
Only thing missing is the "Headless Subclipse Feature".
Should things change so that our plug-in becomes runtime incompatible
with some versions of the subclipse.core plug-in, the I expect to
control that using the dependency match rule (i.e. equivalent,
compatible, perfect, etc.).
One might argue that we make it harder then necessary for our users
should the want our svn support. The counter argument is that it is very
likely that those users already have Subclipse installed and that the
version they have will work. If we include a specific version of the
subclipse.core plug-in in our own feature, we will just cause a lot of
grief.
Kind Regards,
Thomas Hallgren
Philippe Ombredanne wrote:
> Thomas Hallgren wrote:
>
>> Using features and "required" plugins, we can a more lax dependency
>> requirement policy and document that certain features have
>> prerequisites on other features from other vendors.
>>
> Thomas
> Expressing feature level dependencies is often a bad choice, unless you
> created the feature yourself.
> There are explicit guidelines from the Eclipse platform team to avoid
> that, and all project that used to have such dependency are
> porgressively replacing that by a plugin level dependency.
> The reason is that your plugins are dependent no matter what on third
> party plugins.
> When you had another dependency from features to features, you end
> creating a double whammy.
> You get dependent on the third plugins, their versions AND the certain
> way they are packaged in a feature, and the version of that feature.
> And you can find situations where you plugins level dependencies are
> satisfied, yet your feature level dependencies will be not.
> It has been the sourec of quite a few bugs in the update area.
> The versioning guidelines from the platform team may help you in your
> decision:
> http://wiki.eclipse.org/index.php/Version_Numbering#Versioning_features
> Note that WTP and a few other projects which used to have such deps are
> removing them.
>
> So my 2 cents would be to avoid being dependent on Subclipse features,
> and instead create your own for your own needs, maintained on your own
> site.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Sun Jan 28 13:52:39 2007