Well don't get me wrong... it's a potentially valuable idea to include that kind of information in the manifest, if even it takes a while for us to figure out the best way to use it.
For example, who or what is the component responsible for installing this bundle in the first place? If it's something like the Eclipse Update Manager, then it could be useful for the Manager to pull down an initial seed bundle and then use the resolver to work out what else is required. I'm sure somebody (probably from IBM...) will pipe up and say "subsystems!" around about now ;-) Neil On Fri, Apr 26, 2013 at 7:31 PM, Raymond Auge <[email protected]>wrote: > 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 >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
