Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [linux-distros-dev] auto-provides and requires for OSGipackages

I guess if you are able to handle all the require and package level deps
here that could work out ok, but the details could be devilish.
There are also deps which are not expressed in manifest btw. There could
be a in fragment (and the host does not knwo about it), or they could in
features.xml when it comes to eclipse plugins.

For instance:
 org.eclipse.help.webapp requires help.base
 org.eclipse.help.ui requires help.appserver, help.base 
 org.eclipse.help.base  requires help and help.appserver
 org.eclipse.help requires has no dep on depx
 org.eclipse.help.appserver has no dep on help

Take now a plugin that provides some help, it will depend on :
org.eclipse.help

So that plugin will dep on help  only, not on the other which would be
neede to get a full help experience
To be fully functional it would need also help.webapp, help.ui,
help.base, and so on

Another example when a plugin only declares:
Import-Package: com.ibm.icu.text
so you give him  the full icu or the trimmed down / minimal icu?
Only a feature will give you that today.

Same stuff could apply to fragments. 

Just one word of caution, manifest express only bundle level deps (which
can be quite complex to resolve already), not product level, so you
cannot rely only on them.
 
-- 
Cheers
Philippe
http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf




> -----Original Message-----
> From: Andrew Overholt [mailto:overholt@xxxxxxxxxx] 
> Sent: Wednesday, April 18, 2007 1:32 PM
> To: pombredanne@xxxxxxxxx
> Cc: linux-distros-dev@xxxxxxxxxxx; 'Pascal Rapicault'
> Subject: RE: [linux-distros-dev] auto-provides and requires 
> for OSGipackages
> 
> 
> On Wed, 2007-18-04 at 13:31 -0700, Philippe Ombredanne wrote:
> > Just to add my 2 cents, there is much mor than just
> > import/export/require like for instance dynamic imports.
> > IMHO unless you use a full pde style resolver like 
> PDEState, you are in
> > for a rough ride to replicate all the features correctly, 
> and be left
> > with a broken dependency resolution.
> 
> We're just trying to get first-level dependencies here.  If 
> each package
> has its own first-level dependencies set correctly, the yum depsolver
> will resolve all the way down the chain.  Do you think there's other
> work to be done?
> 
> Thanks,
> 
> Andrew
> 



Back to the top