On 26/04/13 19:45, Ferry Huberts wrote: > > > On 26/04/13 19:39, Raymond Auge wrote: >> >> On Fri, Apr 26, 2013 at 12:59 PM, Neil Bartlett <[email protected] >> <mailto:[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. >> > > > Don't think you'd be a problem. ..that'd be...
sticky fingers/mind > Again comparing to yum/rpm: > You install (start?) the repo bundle, the framework picks it up and > stores the provided config. Next time you run a resolve your new repo > will be taken into account. > When you remove the bundle, the framework removes the config and the > repo is no longer available. > provided the framework (resolver?) provides the required service of course >> 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] <mailto:[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] <mailto:[email protected]>> wrote: >> >> >> >> >> On Fri, Apr 26, 2013 at 11:14 AM, Ferry Huberts >> <[email protected] <mailto:[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://liferay.com/spain2012> >> > <http://www.liferay.com/spain2012> >> > >> > 16 November 2012 |* Liferay **Italy Symposium* | >> liferay.com/italy2012 <http://liferay.com/italy2012> >> > <http://www.liferay.com/italy2012> >> > >> > >> > >> > >> > _______________________________________________ >> > OSGi Developer Mail List >> > [email protected] <mailto:[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] <mailto:[email protected]> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] <mailto:[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 >> > -- Ferry Huberts _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
