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
