[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cross-project-issues-dev] dependencies, build and P2
- From: Eike Stepper <stepper@xxxxxxxxxx>
- Date: Sun, 19 Dec 2010 09:19:13 +0100
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:22.214.171.124) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
Am 18.12.2010 10:17, schrieb Gunnar Wagenknecht:
Am 17.12.2010 21:17, schrieb Miles Parker:
My feature said it didn't care about what version of BIRT I was
using, yet when deployed it mattered very much. Does this seem wrong
to anyone else?
Ok, there are two different ways to specify your dependencies in
features (feature.xml). This is important to understand because of the
A - "include"
("Plug-ins" as well as "Included Features" tab)
B - "depends on"
I see that there are plugin and feature dependencies possible. Would you say that the plugin dependcies are a relict from times before p2? Wouldn't I duplicate what's in my bundle manifests anyway by specifying plugin dependencies in the feature.xml?
Everything that belongs to (A) will be hard wired to one single version.
Especially when you use "0.0.0" in the feature.xml it will be translated
at build time into that a single version that is available at build
time. Simply put, it's like saying "I need BIRT 2.6.3.v123blah and only
As a result, 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).
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".
However, the downside of (B) is that p2 will only install those
dependencies when using the "planner" mode. The "planner" mode is the
one that it used in "Install New Software..." and "Check For Updates".
For target platforms it varies. If you check "Include required software"
the "planner" will be used. Otherwise the "slicer" will be used which
does not install anything that belongs to (B).
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.