The felix bundlerepository contains all the code needed to generate OBR repositories. This code is leveraged by the maven bundle plugin to generate the obr xml files at compilation time. This plugin also includes a bindex goal (see bundle:index goal on http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html). Two more things: the blueprint information is indirectly leveraged already through the use of manifest headers that are generated by the maven bundle plugin after parsing the blueprint configuration (we've already discussed that, but I tend to think it's more flexible as it can also cover DS, iPojo or other osgi technologies). Last, the OSGi alliance is working on an OBR spec and the felix bundlerepository is supposed to be the reference implementation. Maybe it would make sense to improve the felix implementation rather than having duplicated code ?
On Tue, Mar 8, 2011 at 23:37, Emily Jiang <[email protected]> wrote: > In Apache Aries, our resolver is able to take in any external repositories. > It is also able to generate repository xml by using the following code > snippet (lifted from the module of application itest, > OBRResolverAdvancedTest.java). *By the way, the repository xml generated by > apache aries includes the blueprint service/reference infomation, which > cannot be achived by bindex (a repository generator).* > > private void generateOBRRepoXML(boolean nullURI, String ... bundleFiles) > throws Exception > { > Set<ModelledResource> mrs = new HashSet<ModelledResource>(); > FileOutputStream fout = new FileOutputStream("repository.xml"); > RepositoryGenerator repositoryGenerator = > getOsgiService(RepositoryGenerator.class); > ModelledResourceManager modelledResourceManager = > getOsgiService(ModelledResourceManager.class); > for (String fileName : bundleFiles) { > File bundleFile = new File(fileName); > IDirectory jarDir = FileSystem.getFSRoot(bundleFile); > String uri = ""; > if (!!!nullURI) { > uri = bundleFile.toURI().toString(); > } > mrs.add(modelledResourceManager.getModelledResource(uri, jarDir)); > } > repositoryGenerator.generateRepository("Test repo description", mrs, > fout); > fout.close(); > } > > In order to get a repository xml, end users have to write the code snippet > above, which is not ideal. I propose to provide a jar file containing all > classes needed to generate the repository. The end user will just execute > the jar file and pass in the location of bundles in order to generate a > repository xml. > > At the moment, the classes required for generating repository files are in > the modules of org.apache.aries.application.utils, > org.apache.aries.application.api, org.apache.aries.application.modeller, > org.apache.aries.obr.resolver, org.apache.aries.blueprint, felix bundle > repository. However, I don't want to duplicate the classes due to future > maintence concern. > > Any suggestions on how we can best achive this. > > Thanks > Emily > ================= > Emily Jiang > [email protected] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
