Yes, plug-ins found in the dropins folder
are optional, in the sense that p2 makes a best effort attempt to install
as many of them as possible. If there are conflicting dependencies they
won't all be installed. The best way to find out about these conflicts
is to do a "proper" install of your bundles using the p2 UI.
Add your features to a repository and install the features using Help >
Install New Software". The p2 UI will describe the conflicts and give
you options to deal with them (such as de-selecting one or more features
and installing less features).
>A. If the sat4j solver is given a problem
with a lot of
>constraints, it might not always give me the best possible solution?
>(esp since it considers the plugins from dropins as 'optional'!!)
Well, I think the definition of "best possible"
is the quesiton here. If I understand correctly you have multiple features
or bundles with conflicting dependencies. I think the optimization function
has a number of inputs here - it attempts to minimize perturbation (preferring
what is already installed over newly arrived things), and attempts to satisfy
the most constraints. This won't always result in the most recent version
being selected. For example if there are two bundles requiring the old
version and only one requiring the new version, it might quite reasonably
prefer the old version.
>B. If that is the case, is there a way to work
around >it? I want the latest-and-greatest of all plugins
loaded from my >dropins folder.
No, I don't think there is currently any way to customize
the constraint satisfaction problem or the heuristics used to solve it.
You're welcome to enter an enhancement request to capture this.
Murali Mohan <m.murali@xxxxxxxxx> Sent by: p2-dev-bounces@xxxxxxxxxxx
04/29/2009 11:05 AM
Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>
[p2-dev] Plugins in dropins are optional?
1) I found this in ProfileSynchronizer.java
// the STRICT policy is set when we install things via the UI, we use
it to differentiate between IUs installed
// via the dropins and the UI. (*dropins are considered optional*) If
an IU has both properties set it means that
// it was initially installed via the dropins but then upgraded via
the UI. (properties are copied from the old IU
// to the new IU during an upgrade) In this case we want to remove the
"from dropins" property so the upgrade
// will stick.
So plugins put in /dropins, or those referred by a .link file need
not necessarily be loaded by p2, right?
2) Now the more important question :)
I've been playing around with p2 for a few days now.
This is the story:
I have 3 sets of plugins ( grouped as 3 features) developed inhouse
Let me call them common-feature, first-feature (~20
second-feature (~ 50 plugins).
a) first-feature ( v 3.0.1 ) depends on common-feature
( v 2.1.0
and compatible ie, [2.1.0 , 3.0.0) )
<import feature="common-feature" version="2.1.0"
and other third party plugins such as emf, gef, dtp tools etc
b) second feature ( v 5.0.0 ) depends on common-feature
2.0.1 and compatible ie, [2.1.0 , 3.0.0) )
and other third party plugins such as emf, gef, gem etc
( :( Dont ask me why. The three groups have different release cycles.
Now I want both of these to work together in my eclipse 3.4.2. I would
expect p2 to resolve and load common-feature 2.1.0 , first-feature
Here is my disklayout.
first-feature.link --> points to /first-feature folder
first-feature-tp-dependencies.link --> and so on
features and plugins >
features and plugins >
Now the fun part:
When I start eclipse after adding these links, at times it would load
common-feature 2.1.0 , first-feature and second-feature all
completely and correctly.
(I was testing; so I always made sure that eclipse is started as if it
is the first run. I had a script to replace configuration, p2
folders with new clean ones before I start again)
But at times it would load common-feature 2.0.1 , second-feature
all plugins) and first-feature partially ( those plugins which
not depend on common-feature 2.1.0 plugins).
Probing further, I found that first-feature-tp-dependencies and
second-feature-tp-dependencies had a lot of common tp plugins with
version conflicts. I made sure the common ones all have the same
versions. Thus reducing the "constraints" for the solver
(Projector.java ). And voila!, everything started to
time and again.
So my question is,
A. If the sat4j
solver is given a problem with a lot of
constraints, it might not always give me the best possible solution?
(esp since it considers the plugins from dropins as 'optional'!!)
B. If that is the case,
is there a way to work around
it? I want the latest-and-greatest of all plugins loaded from my
Thanks in advance! Murali.
p2-dev mailing list