Hi, Providing "automatic" OBR bundle descriptions is on the iPOJO roadmap (and is currently under development). It should describe service requirements / capabilities as well as provided and required handlers. The complex stuff comes from the differentiation between factories and instances (only instances require and provide services).
Integrating these capacities inside Bindex or BND could be great. Clement -----Original Message----- From: Guillaume Sauthier [mailto:[EMAIL PROTECTED] Sent: lundi 7 juillet 2008 11:04 To: dev@felix.apache.org Subject: Re: OBR Clement Escoffier a écrit : > Hi, > > I go on my investigations about an OBR for Felix. I'm working on writing > descriptions for all released bundles. Indeed, Bindex generate correctly > package capabilities and requirement in term of package, but is not very > useful about services. The maven-bundle-plugin allows to customize / improve > descriptions. So, my goal is to create these descriptions ASAP (and to try > to discover these descriptions automatically). Given the number of component models available with OSGi, I would like to have automatic discover of the services requirements/capabilities pluggable. I mean, bindex does a great job with packages, but when it comes to services, where can it find the data ? So It could be great to have a way to extend bindex with a pluggable "discovery mechanism": * one that know to look at the SCR xml files * another that knows iPOJO (metadata.xml as well as annotations) * support for service binder * ... WDYT ? --Guillaume BTW, Maybe the same idea could be applied for bnd ? Bnd knows how to look inside spring-dm xml files to discover needed imports, why not have the same for ipojo, scr and so on ? > These descriptions will > greatly help the deployment process as service requirements will be computed > as well as packages. However, this open new issues... we have one artifact > (web console) that requires the HTTP Service that was not released (correct > me if I'm wrong). So, the generated repository is not self-contained. > > Another small issue is about bundles depending on SCR. The SCR runtime > deployment is not automatic as it's neither a service requirement nor a > package requirement. One solution is to add a specific capability to SCR, > and to create a requirement targeting this capability in each bundles > requiring the SCR runtime. In fact, if we go further, this issue will appear > for each extender model (when an extension is deployed before the host). > > Clement > > -----Original Message----- > From: Felix Meschberger [mailto:[EMAIL PROTECTED] > Sent: mercredi 2 juillet 2008 10:49 > To: dev@felix.apache.org > Subject: Re: OBR > > Hi, > > Richard S. Hall schrieb: > >> Sounds good to me...we might quickly find, though, that we need to >> revise how OBR reads the repository files, since currently it reads them >> every time it starts...perhaps we could cache them for some >> [configurable] time so that it doesn't have to go download repository >> files all the time...still, I think it is a good idea.. >> > > Sounds good. We could that simply by leveraging the Caching headers of > the HTTP protocol, such as Last-Modified and ETag. > > > >> Now we just need to finish up with what Clement created to generate our >> desired Felix OBR repo... >> > > Yes. > > Regards > Felix > > > >> -> richard >> >> Felix Meschberger wrote: >> >>> Hi all, >>> >>> After adding OBR referral support (with hop count) as per FELIX-399 >>> recently I started with prototyping a setup for this functionality. I >>> have created a "master repository" at [1] which contains referrals to >>> the Sling repository at [2] and Clement's prototype at [3]. >>> >>> If you update your felix framework to the latest 1.1.0 SNAPSHOT build >>> of the bundlerepository project, which I just deployed to [4], you can >>> add the master repository, for example typing in the Felix Shell >>> >>> obr add-url http://people.apache.org/~fmeschbe/repository.xml >>> >>> Listing the existing repository URLs should then give you all three >>> mentioned above. >>> >>> Now, what does this help ? IMHO this proves the idea, that we can have >>> a single master repository referring to other repositories without >>> requiring to duplicate entries. >>> >>> So we could provide such a master repository at our site, e.g. >>> http://felix.apache.org/repository.xml (this is not there yet ;-) ). >>> And upon requests by projects we might add referrals of a defined >>> depth (I would say 1 by default, but not too big, either). >>> >>> WDYT ? >>> >>> Regards >>> Felix >>> >>> [1] http://people.apache.org/~fmeschbe/repository.xml >>> [1] http://people.apache.org/~fmeschbe/sling-repository.xml >>> [3] http://oscar-osgi.sourceforge.net/obr-repo/releases.xml >>> [4] >>> >>> > http://people.apache.org/repo/m2-snapshot-repository/org/apache/felix/org.ap > ache.felix.bundlerepository/1.1.0-SNAPSHOT/org.apache.felix.bundlerepository > -1.1.0-20080627.095454-3.jar > > > > >
