Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] dependencies, build and P2

Thanks for the very thorough explanation, Gunnar. (Maybe my role in this ecosystem is to be willing to be stupid!)

On Dec 18, 2010, at 1:17 AM, Gunnar Wagenknecht wrote:
> 
> Ok, there are two different ways to specify your dependencies in
> features (feature.xml). This is important to understand because of the
> deployment implications.
> 
> A - "include"
> ("Plug-ins" as well as "Included Features" tab)
> 
> B - "depends on"

> 
> As a result [of case A], p2 will install that particular version. In theory p2 is
> able to install multiple versions of a bundle. However, most of the time
> Eclipse plug-ins are marked as singletons. Thus, p2 can't succeed
> because in order to install a different version the other version must
> be uninstalled (which isn't possible most of the time)

I don't know what is going on in my case then, because I never use "includes" unless 1) The feature/plugin is actually part of my project or 2) I know that it won't be provisioned anywhere else (in my case this is only true for one special case -- GEF3D isn't part of common infrastructure. The only thing I can see in my case is that one version requirement snuck into a plugin, but that wasn't satisfied anyway -- the minor version was different. I had no such versioning for feature but maybe the plugin dependency was enough. Parenthetically, I really wish there were a way to turn off the PDE default behavior of assigning exact version by default for requirements -- invariably I forget to unset it.

> In contrast, everything that belongs to (B) will be translated into a
> version range. The benefit of a version range is that it (usually)
> better expresses the case of 3rd party dependencies. Simply put, it's
> like saying "I need BIRT 2.6 or any other compatible version".

OK, so perhaps in my case, the minor version specified in the plugin above "froze" the feature requirement down to major version compatibility?
> 
> This leads to a simple rule for the release train. If you don't care
> about target platforms then just use (B) only only put your own projects
> (that you build from source) under (A).
> 
> If, however, you are producing an SDK for target platforms you may need
> to put some dependencies under (A) otherwise your SDK won't be usable
> when the target platform is in "slicer" moder. "Slicer" mode must be
> used for cross-platform target platforms which should contain
> fragments/plug-ins for various platforms (eg. Linux, Windows, etc.).
> This is usually the case for target platforms shared within teams.

OT a bit now, but this resolves some confusion I had when trying to put together SDKs (complete AMP based IDEs) because it sounds like slicer is used for RCP/Product builds as well -- I saw that I needed to create a separate feature for the SDK and wondered why. Would a simple rule then be: never use include (except as above when you *know* it won't be provisioned from anywhere else) in the "project" features defining a complete set of features, and instead to always put includes in separate projects that wrap up all of the dependencies that you are packaging. ? I've mentioned before the thought that there could be a different project for products altogether with corresponding artifacts, and an extreme reading of that would simply dis-allow depends on in products/platforms and includes in features. From what I've seen of examples that work well this seems to be the best practice.

cheers,

Miles



Back to the top