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]
