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.
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.

> 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

Reply via email to