Hi, A lot of Apache project ship OSGi bundles now. For the one I know the best, for MINA everything is packaged as bundle even AsyncWeb, using bnd plugin for maven. So if this kind of OBR appear I'm sure a lot of Apache project will want to push ther bundles.
Now if we need one repository for everything like maven or repository links, well I leave the answer to the specialists :) Perhaps infra could help here ? Julien 2008/5/26 Felix Meschberger <[EMAIL PROTECTED]>: > Hi, > > I have been thinking about this issue and been discussing it with > Carsten. And we came up with a very simple solution: The main point is, > that the repository.xml file and the artifacts referred to need not be > in the same location, right ? > > Starting from this, the solution would be that we might provide the > repository.xml file from the Felix site and have the bundles where they > already are: in the maven repository. > > So upon the release of one of the Felix bundles, we just add a record > for the bundle into the repository.xml pointing to the maven repository. > That's it, I would say. > > So far so good. But there will be other projects -- just talking of > Apache for the moment, but OPS4J also comes to mind -- which have > bundles to distribute. Here comes the <referral> element of the > repository.xml file (section 5.5.4 in OSGi RFC 112): We create a central > repository.xml file, into which referrals to other projects may be > entered. Each project thus maintains its own repository.xml. > > For example: > > global-repository.xml > ---> referral to Apache Felix repository.xml > ---> referral to Apache Sling repository.xml > ---> referral to Apache Commons repository.xml > > I think, this solution can be easily and quickly implemented and does > not need too much additional network traffic. > > A further development step could be to have separate repository.xml > files for releases and SNAPSHOTs. We could arrange to update the > SNAPSHOT repository.xml file by means of the maven-bundle-plugin (would > require to be able to specify the actual location repository.xml file) > upon deplyoment of the SNAPSHOTs... > > > WDYT ? > > Regards > Felix > > > Am Freitag, den 16.05.2008, 10:40 -0400 schrieb Richard S. Hall: >> If I understand correctly, Clement is proposing something like this: >> >> releases/ >> bundleA-v1/ >> bundleA-v2/ >> bundleB-v1/ >> bundleC-v1/ >> bundleC-v2/ >> pom.xml >> >> The above represents the structure of our releases directory. The >> pom.xml will refer to the most recent version of each release bundle, e.g.: >> >> pom.xml >> artifactId=bundleA,version=2 >> artifactId=bundleB,version=1 >> artifactId=bundleC,version=2 >> >> The purpose of this pom file is largely to document which subprojects >> should be made available in our repo. However, if you use it to issue >> the mvn deploy command on this pom, then it will deploy the set of all >> current releases to the repo. >> >> This is obviously inefficient if only one bundle has been updated since >> it will deploy all bundles. To avoid this, though, you can simply 'cd' >> into the precise subproject release directory and issue that mvn deploy >> command from there, then only the newly released bundle will be deployed. >> >> Clearly, this process is simplistic, but it is probably better than >> nothing, which is the current approach. The idea here is that we could >> just incorporate it as part of our normal release process, where after >> we tag a released bundle in the releases directory, then we update the >> version in the pom.xml and then deploy it to the repo. >> >> What do you think? >> >> -> richard >> >> [EMAIL PROTECTED] wrote: >> > If I understand well, Clement's proposal supposes that somebody deploys >> > the whole set of felix bundles in a centralized manner. >> > >> > Another possibility is to incrementally evolve the remote repository.xml >> > file, in a similar manner to the local repository.xml file. Using this >> > method for the official felix site would allow the person responsable for >> > deploying some felix subproject on the maven repository to deploy the same >> > bundles on the obr. >> > >> > This means using the same kind of command line as Clement, but at a >> > subproject level (not at the root): >> > mvn deploy -DremoteOBR >> > -DaltDeploymentRepository=plop-plop.felix.releases::default::scp://deploymentmachine/mypath >> > deploys the artifacts on the remote obr AND updates the remote >> > repository.xml file . >> > >> > I'm not involved in felix development, so I don't know what the policy is >> > concerning deployment on the maven repository. If one considers that felix >> > contains some subprojects (sets of bundles) that evolve rather >> > independently from eachother, this incremental method can be relevant. >> > >> > Regards, >> > >> > Anne >> > >> > -----Message d'origine----- >> > De : Richard S. Hall [mailto:[EMAIL PROTECTED] >> > Envoyé : jeudi 15 mai 2008 15:43 >> > À : users@felix.apache.org; [EMAIL PROTECTED] >> > Objet : Re: obr for felix bundles? >> > >> > I think the stylesheet can be figured out one way or the other...what we >> > really need to do is decide if we like the approach that Clement has >> > proposed and, if so, where should physically generate the repository... >> > >> > -> richard >> > >> > Clement Escoffier wrote: >> > >> >> Hi, >> >> >> >> I change the XSLT file, now there is colors :-) >> >> >> >> Clement >> >> >> >> >> >> >> >> >> >>> -----Message d'origine----- >> >>> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> >>> ftgroup.com] Envoyé : jeudi 15 mai 2008 03:37 À : >> >>> users@felix.apache.org Objet : RE: obr for felix bundles? >> >>> >> >>> Hi Clement ! >> >>> I have personally a slight preference for the stylesheet coming from >> >>> the OSGi Web site (attached file) . >> >>> Apart from the style itself (better for presbyopian eyes), it sorts >> >>> the bundles alphabetically. I see you have commented this feature in >> >>> yuor xsl file. >> >>> Of course that's a matter of personal preference, and that's not the >> >>> main point ! >> >>> Best regards, >> >>> Anne >> >>> -----Message d'origine----- >> >>> De : Clement Escoffier [mailto:[EMAIL PROTECTED] >> >>> Envoyé : jeudi 15 mai 2008 03:42 >> >>> À : users@felix.apache.org >> >>> Objet : RE: obr for felix bundles? >> >>> >> >>> Hello, >> >>> >> >>> I attach the Didier's XSLT stylesheet to the generated XML file. >> >>> The result is available here : >> >>> http://plop-plop.net/obr/repository.xml >> >>> >> >>> Clement >> >>> >> >>> >> >>> >> >>>> -----Message d'origine----- >> >>>> De : [EMAIL PROTECTED] >> >>>> [mailto:[EMAIL PROTECTED] ftgroup.com] Envoyé : mardi 13 mai 2008 06:25 >> >>>> À : >> >>>> users@felix.apache.org Objet : RE: obr for felix bundles? >> >>>> >> >>>> Great idea ! >> >>>> >> >>>> Not only it will ease people getting started with felix, but it can >> >>>> help convince people giving a try : >> >>>> if your repository.xml refers to an obr2html.xsl file, and you show >> >>>> people the repository in a browser, you will have the same "waw" >> >>>> effect as with the old Oscar repository. You see a nice list of >> >>>> already existing bundles, and if you follow the "doc" link it goes >> >>>> to the doc etc.. >> >>>> >> >>>> Regards, >> >>>> Anne >> >>>> >> >>>> -----Message d'origine----- >> >>>> De : peter.doornbosch [mailto:[EMAIL PROTECTED] >> >>>> Envoyé : samedi 10 mai 2008 11:43 >> >>>> À : users@felix.apache.org >> >>>> Objet : Re: obr for felix bundles? >> >>>> >> >>>> Hi Richard, >> >>>> >> >>>> I think it would be great if you can arrange this. I think that >> >>>> >> >>>> >> >>> people >> >>> >> >>> >> >>>> that are new to OSGi can have a hard time to get started with felix >> >>>> >> >>>> >> >>> (i >> >>> >> >>> >> >>>> noticed this a few times) and i think that being able to install >> >>>> >> >>>> >> >>> felix >> >>> >> >>> >> >>>> bundles in a simple and convenient way might help. >> >>>> >> >>>> Regards, >> >>>> Peer >> >>>> >> >>>> >> >>>> On 9 May , 2008, at 16:11 , Richard S. Hall wrote: >> >>>> >> >>>> >> >>>>> There currently is not. We definitely need this. It basically >> >>>>> >> >>>>> >> >>>> involves >> >>>> >> >>>> >> >>>>> determining at least two things: >> >>>>> >> >>>>> 1. How should we go about generating the repo? >> >>>>> * We have the capability to generate OBR repository files, >> >>>>> >> >>>>> >> >>>> but >> >>>> >> >>>> >> >>>>> how do we get one generated for our current set of >> >>>>> >> >>>>> >> >>> released >> >>> >> >>> >> >>>>> bundle versions? >> >>>>> 2. Where do we put the repository? >> >>>>> >> >>>>> I don't really know the best way to do (1). As for (2), I am not >> >>>>> sure if it matters, I don't think it needs to be hosted on our >> >>>>> Apache >> >>>>> >> >>>>> >> >>>> site. >> >>>> >> >>>> >> >>>>> I could put the repo on my own personal web site or we could just >> >>>>> put them on the Source Forge web site. >> >>>>> >> >>>>> -> richard >> >>>>> >> >>>>> p.s. Sorry to cross post, it is not necessary to cross post >> >>>>> replies...I just want to make sure that this discussion is seen on >> >>>>> >> >>>>> >> >>>> the >> >>>> >> >>>> >> >>>>> dev list. >> >>>>> >> >>>>> peter.doornbosch wrote: >> >>>>> >> >>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> I wonder if there is an obr repository for the (current versions >> >>>>>> >> >>>>>> >> >>> of >> >>> >> >>> >> >>>>>> the) felix bundles. When i start felix (1.0.4), obr is configured >> >>>>>> with the url http://oscar- >> >>>>>> >> >>>>>> >> >>> osgi.sourceforge.net/obr2/repository.xml, >> >>> >> >>> >> >>>>>> which contains only a few really old bundles.... >> >>>>>> >> >>>>>> Regards, >> >>>>>> Peter >> >>>>>> >> >>>>>> >> >>>>>> ------------------------------------------------------------------ >> >>>>>> >> >>>>>> >> >>> - >> >>> >> >>> >> >>>>>> - >> >>>>>> >> >>>>>> >> >>>> - >> >>>> >> >>>> >> >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> ------------------------------------------------------------------- >> >>>>> >> >>>>> >> >>> - >> >>> >> >>> >> >>>>> - To unsubscribe, e-mail: [EMAIL PROTECTED] >> >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >> >>>>> >> >>>>> >> >>>>> >> >>>> -------------------------------------------------------------------- >> >>>> - To unsubscribe, e-mail: [EMAIL PROTECTED] >> >>>> For additional commands, e-mail: [EMAIL PROTECTED] >> >>>> >> >>>> >> >>>> -------------------------------------------------------------------- >> >>>> - To unsubscribe, e-mail: [EMAIL PROTECTED] >> >>>> For additional commands, e-mail: [EMAIL PROTECTED] >> >>>> >> >>>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >>> For additional commands, e-mail: [EMAIL PROTECTED] >> >>> >> >>> >> >>> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
