Re: [p2-dev] Plugins in dropins are optional?

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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.

John

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>

To	p2-dev@xxxxxxxxxxx
cc
Subject	[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 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) )
   <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 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
dropins folder.

Thanks in advance! Murali.
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev