Hi,

Am Dienstag, den 27.05.2008, 11:25 +0200 schrieb Julien Vermillard:
> 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 ?

Sure.

But my point is that we do NOT replicate the actual bundle files but
keep the in the Maven Repository, where they already are. We just create
repository.xml files that refer to the existing bundles in the Maven
Repository.

The repository.xml file is used by the OSGi Bundle Repository (Client if
you wish) to find available and required bundles. It only contains
descriptions of the available bundles in terms of bundle names,
versions, capabilities (Export-Package mostly) and requirements
(Import-Package mostly) and some more attributes. These files tend to be
small compared to the actual bundle files.

Regards
Felix

> 
> 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
> >> > À : [email protected]; [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 À :
> >> >>> [email protected] 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
> >> >>> À : [email protected]
> >> >>> 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 À :
> >> >>>> [email protected] 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
> >> >>>> À : [email protected]
> >> >>>> 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]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to