Robert Griffin - NOAA Affiliate Senior Application Engineer DGP CLASS Team / CSC 2000 Greenriver Drive, Fairmont, WV Phone: 304-534-3128 ext. 167 Fax: 304-534-5216
On Apr 26, 2013, at 2:26 PM, [email protected] wrote: > Send osgi-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.osgi.org/mailman/listinfo/osgi-dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of osgi-dev digest..." > > > Today's Topics: > > 1. Re: idea for repository management & configuration (Neil Bartlett) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 26 Apr 2013 19:26:07 +0100 > From: Neil Bartlett <[email protected]> > To: OSGi Developer Mail List <[email protected]> > Subject: Re: [osgi-dev] idea for repository management & configuration > Message-ID: > <CAPr=90m9vs_r5h3agmsgns5nohxx4_n+sl2b43bbd0fdyip...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mail.osgi.org/pipermail/osgi-dev/attachments/20130426/8dfdce4a/attachment.html> > > ------------------------------ > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > End of osgi-dev Digest, Vol 78, Issue 32 > ****************************************
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
