[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 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.