Thanks to Alasdiar for your recommendation. I will give it a go. Guillaume, thanks for your input. Felix bundle repositiory generation takes care of blueprint, DS etc info if the bundles are generated using maven bundle plugin. The fact is that not every bundle is generated by using maven plugin. We need to cater for all scenarios. Therefore, I think we should provide our own generator.
On Wed, Mar 9, 2011 at 9:58 AM, Alasdair Nottingham <[email protected]> wrote: > On 9 March 2011 07:25, Guillaume Nodet <[email protected]> wrote: > > 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). > > -1 -1 -1 obviously, and lets not go on here. > > > 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 ? > > I disagree. First of all we already have the code to do this in apache > aries > as indicated by Emily. Secondly she isn't trying to create a maven plugin > but something that can be used from a command line to generate an OBR based > on a directory containing bundles. This is very different from what the > maven-bundle-plugin does and is, in my view, valuable. > > > > > > > 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 > > > > > > -- > Alasdair Nottingham > [email protected] > -- Thanks Emily ================= Emily Jiang [email protected]
