Got it! Was a wishful over-simplification I guess.
On Fri, Apr 26, 2013 at 2:26 PM, Neil Bartlett <[email protected]> wrote: > 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 > -- *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
