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