No, this is a fragment which is used at build time to generate the correct repository.xml in your ~/.m2/repository.xml It does not need to be included in the bundle at all.
On Thu, Feb 25, 2010 at 13:41, Alasdair Nottingham <[email protected]> wrote: > Guillaume, > > I'm still really confused by this change. Are you saying that in order > for the BundleInfo implementation to know what services are required > and used the bundle must contain an OBR repository.xml of the bundle? > > Thanks > Alasdair > > On 25 February 2010 08:41, Guillaume Nodet <[email protected]> wrote: >> On Thu, Feb 25, 2010 at 09:00, David Jencks <[email protected]> wrote: >>> Is this some standard I'm not aware of? What are these used for? How? >>> When? Is this documented somewhere? They look like repository.xml files, >>> is there a good reason for not naming them repository.xml? And how do they >>> differ from what the bundle plugin generates for a bundle? >> >> Those are fragments that are used by the bundle plugin to generate additional >> requirements and capabilites. I've introduced them because the syntax for >> the Export-Service / Import-Service headers is insufficient to capture all >> the >> semantics. Those fragments are used to generate the repository.xml in your >> ~/.m2/repository/repository.xml >> >> FWIW, I've kept the headers because even if they do not capture the whole >> semantic, it still gives a good idea. >> >> One idea that has been proposed is also to enhance the maven bundle plugin >> to introspect blueprint bundles so as to find out which services are imported >> and exported. I suppose when it's done, those OBR files can be removed and >> maybe even the headers if they are generated. >> >> Makes sense ? >> >>> In geronimo we're experimenting with building up a bundle repository from >>> repository.xml, embedded in geronimo plugins, that are constructed from the >>> maven dependencies of the plugin. Our hope is that this will give control >>> over the repository contents visible to the server yet allow it to be >>> extensible based on what is installed into the server. >> >> I have a small tool on my computer (a hacked version of bindex) which >> can be used >> to scan a maven repository and turn it into a repository.xml with mvn: >> urls in case >> you're interested. >> >>> thanks >>> david jencks >>> >>> On Feb 24, 2010, at 10:35 PM, Guillaume Nodet wrote: >>> >>>> Nothing, but that's part of the definition of the bundle, not really >>>> it's content per se, so I was thinking it make sense to put it there, >>>> but i'd have no problem in moving it in src/main/resources. Actually, >>>> I think it's embedded in the jar, but that's only because I did not >>>> found a way not to. >>>> >>>> On Wed, Feb 24, 2010 at 23:54, David Jencks <[email protected]> >>>> wrote: >>>>> >>>>> What is so special about obr.xml files that they aren't in >>>>> src/main/resources? >>>>> >>>>> thanks >>>>> david jencks >>>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> Open Source SOA >>>> http://fusesource.com >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > > > > -- > Alasdair Nottingham > [email protected] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
