Hi, As Guillaume said: Apache Felix BundleRepository has the code and it is used by the Maven Bundle Plugin.
If you want to create some command line tool, which I think is an excellent idea, you should really leverage what's there in the Apche Felix BundleRepository code. Because, and this is the most important point: This will allow users of the tools a seamless experience and a single point of fixing issues. Regards Felix Am Mittwoch, den 09.03.2011, 10:10 +0000 schrieb Emily Jiang: > 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] > > > > >
