[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[p2-dev] Plugins in dropins are optional?
- From: Murali Mohan <m.murali@xxxxxxxxx>
- Date: Wed, 29 Apr 2009 15:05:14 -0000
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=FwWwOFdaWVeITpf57+YXIoEG/iTYr9+eudgm4VOIewW/FhtdgZVy+dcdZ4g9eF0VKV bGNcfazOIj49PD7XD2el03dgsD+lcUCinMv4L04F6VoyoZq8ovjrspOAWZz9tdsg7Hw5 6OhQUSxp262eDpxOaT+xLp5vVdlUNuUzXrG28=
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 plugins) and
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" match="compatible" />
and other third party plugins such as emf, gef, dtp tools etc
b) second feature ( v 5.0.0 ) depends on common-feature ( v
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
first-feature_3.0.1 & common-feature_2.1.0 plugins
second-feature_5.0.0 & common-feature_2.0.1 plugins
<tp features and plugins >
<tp 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 do
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 load correctly
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.