[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[p2-dev] Plugins in dropins are optional?
|
Hi All,
1) I found this in ProfileSynchronizer.java
// the STRICT policy is set when we install things via the UI, we
useit 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) )
<requires>
<import feature="common-feature" version="2.1.0" match="compatible" />
.......
.......
</requires>
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
and second-feature
Here is my disklayout.
/dropins
first-feature.link --> points to /first-feature folder
first-feature-tp-dependencies.link --> and so on
second-feature.link
second-feature-tp-dependencies.link
/first-feature
/eclipse
/features
first-feature_3.0.1/
feature.xml
common-feature_2.1.0/
feature.xml
/plugins
first-feature_3.0.1 & common-feature_2.1.0 plugins
/second-feature
/eclipse
/features
second-feature_5.0.0/
feature.xml
common-feature_2.0.1/
feature.xml
/plugins
second-feature_5.0.0 & common-feature_2.0.1 plugins
/first-feature-tp-dependencies
/eclipse
<tp features and plugins >
/second-feature-tp-dependencies
/eclipse
<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 started 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
dropins folder.
Thanks in advance! Murali.