Not really. The resolver is just a service that resolves a set of capabilities and requirements, and works out how they should be wired up. The OSGi Framework uses this resolver, but it only operates on the set of bundles that are already installed in the framework, and it never goes out to repositories.
To pull in dependencies from outside the framework, you need something like a management agent, and that agent could choose to use the resolver service, but it doesn't have to. Another use-case is "ahead of time" resolution such as we provide in Bndtools. So it's that management agent, or that tool, that would have to look at and use your proposed metadata. Neil On Fri, Apr 26, 2013 at 7:19 PM, Raymond Auge <[email protected]>wrote: > But isn't the R5 resolver doing just that? > > In bndtools, the R5 resolver is collecting all the dependencies and > creating a complete runtime, and effectively pulling from a pre-configured > list of repositories. > > All this is doing is adding into that mix a mechanism to enable resolution > of potentially missing resources by letting a bundle declare that it knows > from where it can be fully resolved. > > Ray > > > On Fri, Apr 26, 2013 at 2:11 PM, Neil Bartlett <[email protected]>wrote: > >> No I think that's a bad mixing up of the levels. To use an analogy, it's >> like having your data access layer depend on the UI ;-) >> >> I think this idea needs some serious thought. The generic >> capability/requirement model may not be right for it, because it's metadata >> which is intended to be read and acted upon by the provisioning agent, and >> certainly not by the OSGi Framework. >> >> Neil >> >> >> >> On Fri, Apr 26, 2013 at 6:39 PM, Raymond Auge >> <[email protected]>wrote: >> >>> >>> On Fri, Apr 26, 2013 at 12:59 PM, Neil Bartlett <[email protected]>wrote: >>> >>>> Yep... >>>> >>>> Require-Capability: osgi.service; >>>> filter:="(objectClass=org.example.foo.MyService)"; effective:=active; >>>> resolution:=optional; >>>> >>> >>> Except in this case, I would want effective to be the default resolve. >>> The reason being that, I would potentially want the repo I am declaring >>> dependency on to be added before resolving (since I may need parts that are >>> in that repo in order to completely resolve). >>> >>> I'm not sure if that's even possible. >>> >>> Ray >>> >>> >>>> >>>> (the 'effective' directive is not directly related to optionality, but >>>> is probably a good idea when talking about a service dependency) >>>> >>>> Neil >>>> >>>> >>>> On Fri, Apr 26, 2013 at 5:56 PM, Raymond Auge <[email protected] >>>> > wrote: >>>> >>>>> One further question, is it possible to have an "optional" >>>>> Require-Capability? >>>>> >>>>> I'm trying to think of the semantics around being able to add a repo >>>>> if there is an repo admin service, but if there isn't, just carry on, >>>>> falling back to existing behaviour which would fail to >>>>> resolve the bundle unless it's dependencies are met in traditional >>>>> manner. >>>>> >>>>> - Ray >>>>> >>>>> >>>>> On Fri, Apr 26, 2013 at 11:31 AM, Raymond Auge < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 26, 2013 at 11:14 AM, Ferry Huberts >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 26/04/13 17:08, Raymond Auge wrote: >>>>>>> > Hello All, >>>>>>> > >>>>>>> > (this may already exist, if so forgive the noise... and then please >>>>>>> > point me to it :) ) >>>>>>> > >>>>>>> > Does it make any sense to have a means for bundles to declare >>>>>>> their host >>>>>>> > repository, and if there is such a "capability" installed in the >>>>>>> > framework, that the repository be registered automatically with >>>>>>> the repo >>>>>>> > admin? >>>>>>> > >>>>>>> > I'm taking as example the Debian feature (I believe it originated >>>>>>> in >>>>>>> > Debian first) that a deb can register it's host repository with the >>>>>>> > system. From that point, dependencies and updates are automatically >>>>>>> > detected and handled. >>>>>>> > >>>>>>> > For example, when you install the Google Chrome deb (after >>>>>>> downloading >>>>>>> > the binary directly from their site) it registers the Google Chrome >>>>>>> > repository with the system and from that point you never have to >>>>>>> go get >>>>>>> > updates manually. >>>>>>> >>>>>>> >>>>>>> Chrome does this because the only thing in that repo is Chrome. >>>>>>> >>>>>>> Looking at rpm/yum: normally you'd install an rpm package to make the >>>>>>> repository known. >>>>>>> >>>>>>> So that would translate to a 'my-repository-bundle.jar' that would >>>>>>> configure the framework with the extra repository information. >>>>>>> >>>>>> >>>>>> Sure! It was an example. There are others though as you demonstrate. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> I like the idea :-) >>>>>>> >>>>>> >>>>>> Cool! >>>>>> >>>>>> Would this be >>>>>> - "requiring" a capability (the repo admin) or >>>>>> - "providing" a capability (a repo, implied dependency on repo admin) >>>>>> or >>>>>> - both (a combination of requiring the repo admin, and providing a >>>>>> repo, nothing implied)? >>>>>> >>>>>> - Ray >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> > >>>>>>> > If such a mechanism could be acted upon early in the installation >>>>>>> of a >>>>>>> > bundle, it could actually provide a place for retrieving any actual >>>>>>> > dependencies required for the bundle from the host repository. >>>>>>> > >>>>>>> > This would be great feature as you could promote a single binary >>>>>>> > somewhere as a download, which would auto-magically ensure >>>>>>> dependencies >>>>>>> > were met on deploy even without interaction by the user doing the >>>>>>> > installation. >>>>>>> > >>>>>>> > -- >>>>>>> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>>>> > <http://twitter.com/#!/rotty3000> | Senior Software Architect >>>>>>> > | *Liferay, Inc.* <http://www.liferay.com> < >>>>>>> https://twitter.com/#!/liferay> >>>>>>> > >>>>>>> > --- >>>>>>> > >>>>>>> > 24-25 October 2012 |* Liferay **Spain Symposium* | >>>>>>> liferay.com/spain2012 >>>>>>> > <http://www.liferay.com/spain2012> >>>>>>> > >>>>>>> > 16 November 2012 |* Liferay **Italy Symposium* | >>>>>>> liferay.com/italy2012 >>>>>>> > <http://www.liferay.com/italy2012> >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > OSGi Developer Mail List >>>>>>> > [email protected] >>>>>>> > https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>>>> > >>>>>>> >>>>>>> -- >>>>>>> Ferry Huberts >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>>> <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, >>>>>> Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> >>>>>> >>>>>> --- >>>>>> >>>>>> 24-25 October 2012 |* Liferay **Spain Symposium* | >>>>>> liferay.com/spain2012 <http://www.liferay.com/spain2012> >>>>>> >>>>>> 16 November 2012 |* Liferay **Italy Symposium* | >>>>>> liferay.com/italy2012 <http://www.liferay.com/italy2012> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>> <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, >>>>> Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> >>>>> >>>>> --- >>>>> >>>>> 24-25 October 2012 |* Liferay **Spain Symposium* | >>>>> liferay.com/spain2012 <http://www.liferay.com/spain2012> >>>>> >>>>> 16 November 2012 |* Liferay **Italy Symposium* | >>>>> liferay.com/italy2012<http://www.liferay.com/italy2012> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OSGi Developer Mail List >>>>> [email protected] >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> [email protected] >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>> >>> >>> >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, >>> Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> >>> >>> --- >>> >>> 24-25 October 2012 |* Liferay **Spain Symposium* | >>> liferay.com/spain2012<http://www.liferay.com/spain2012> >>> >>> 16 November 2012 |* Liferay **Italy Symposium* | >>> liferay.com/italy2012<http://www.liferay.com/italy2012> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, > Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> > > --- > > 24-25 October 2012 |* Liferay **Spain Symposium* | > liferay.com/spain2012<http://www.liferay.com/spain2012> > > 16 November 2012 |* Liferay **Italy Symposium* | > liferay.com/italy2012<http://www.liferay.com/italy2012> > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
