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
