Hi, Comments in line,
Regards, Tim ---------------------------------------- > Date: Wed, 9 Mar 2011 11:31:42 +0100 > Subject: Re: [Discussion] Provide an OBR repository generator > From: [email protected] > To: [email protected] > > On Wed, Mar 9, 2011 at 10:58, Alasdair Nottingham wrote: >> On 9 March 2011 07:25, Guillaume Nodet 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. > > The code predates the one in aries. The code is in the felix > bundlerepository jar, so it's not a maven bundle plugin. The maven > bundle plugin just happen to use that code too. > > The code could easily be enhanced to parse blueprint too if that's a > requirement for you. > > I just wanted to express the fact that the code in felix will be > improved and enhanced to implement the OBR spec when it's out, so the > same work will have to be done in aries too. > I just think it's a waste of time to maintain this duplicated code, > but it's not my time ... > I agree that it would be nice to improve the OBR code and that dual maintenance is a bad thing. On the other hand previous attempts from Aries committers to raise bugs and provide patches for OBR have not achieved much. Emily has several outstanding bugs and I've had to get by patching my own one off fixes. We're at a bit of a loss because for the most part we haven't had much feedback where we have raised JIRAs. Is there something more we should be doing? Would it be helpful if a couple of Aries committers got commit access to OBR? I'm sure nobody here wants to duplicate code, I think we're just not sure how best to maintain OBR for our needs. The status quo is definitely not working, it would be great if we could find a way to improve it. >> >>> >>> >>> On Tue, Mar 8, 2011 at 23:37, Emily Jiang 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 mrs = new HashSet(); >>>> 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] >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com
