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>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
