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
