-----Original Message----- From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: mercredi 23 juillet 2008 17:18 To: dev@felix.apache.org Subject: Re: OBR Felix Meschberger wrote: > Maybe we will discover missing parts over time and can fix those as we > encounter them based on the concrete use case. > > As for feeding the repository.xml file on our site: I assume this will > be one of the tasks to be done after a release has been voted. The > release manager should update the repository.xml file. > > The easiest would be if we could run a maven plugin during release > creation which creates a repository.xml fragment, which we may simple > paste into the repository.xml file ? I would prefer that we have some way of also automatically merging the repo XML fragment too.` Updating the repository file is simple when the obr.xml file describing the bundle is created (this file contains provided and required services, but can be used to contain any description). To update the repository, the following maven command works with the latest maven-bundle-plugin: mvn clean install org.apache.felix:maven-bundle-plugin:deploy -Dprefix=http://repo1.maven.org/maven2/ -DremoteOBR=releases.xml -DaltDeploymentRepository=local::default::file:/Users/clement/Documents/work spaces/ipojo-dev/releases Just change the deployment repository to use a non-local location. Remark the prefix indicating the URL prefix to use for the deployed bundles. It means that a repository can contain bundles from different maven repositories. So this command update the OBR file and does not deploy the bundle on a maven repository. Once the repository is created, I have a simple checker (to improve) checking the consistency of the generated OBR file. Basically, it checks the self-consistency of the repository (see the generated HTML file). Related to this is that I assume we will keep our previous versions available in our repo, right? If so, I will likely implement a few changes in the command-line interface for OBR to make it work a little better when we have lots of different versions of the same bundle. The described way just add or update the bundle description (an update occurs only when the same symbolic-name/version is already present). If a new version of the bundle is deployed, the description is added. So, we will get several version of each bundles soon (I think it's already the case as I deployed an old version of one bundle). I don't know if it's an issue right now, but we'll be able to move older version to another repository file when it'll become worthwhile. Clement > > Regards > Felix > >> >> Regards, >> >> Clement >> >> -----Original Message----- >> From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: lundi 7 >> juillet 2008 04:57 >> To: dev@felix.apache.org >> Subject: Re: OBR >> >> Clement Escoffier wrote: >>> 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). These descriptions will >>> greatly help the deployment process as service requirements will be >> computed >>> as well as packages. >> >> Yes, that would be a good idea. >> >>> 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. >> >> Hmm. We should probably just go ahead and release HTTP Service. >> >>> 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). >>> >> >> Yes, this is an issue. As you say, the only way to resolve it >> currently would be to add custom capability/requirements in the SCR >> and client bundles. Not much else we can do. At best we can define >> something to put in the manifest so that bindex can pick it up and >> generate the appropriate dependency. >> >> -> richard >> >>> 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 >>> >> >>
