Hi David, When use the obr:geronimo-install command, must input the "* symbolicName,version*" Now I use the *etc/obr.xml* file to find the maven coordinates(the uri info of the resource element) by the symbolic name and the version that the user input.
On Fri, Aug 12, 2011 at 11:43 AM, David Jencks <[email protected]>wrote: > I see that karaf is starting an obr subproject, "cave", just added to the > karaf sandbox. Can you tell how similar this is to your goals? > > http://svn.apache.org/repos/asf/karaf/sandbox/jbonofre/cave/trunk/ > > I haven't had time to look into your proposal yet. I have one question, > how do you figure out maven coordinates in the geronimo repository for a > bundle that only has a symbolic name? > > <http://svn.apache.org/repos/asf/karaf/sandbox/jbonofre/cave/trunk/>thanks > david jencks > > On Aug 11, 2011, at 3:15 AM, Yi Xiao wrote: > > Hi Jark, I'v seen your comments in 5939 and reference here for convenience > * > -------------------------------------------------------------------------- > * > *1) Don't forget about the license headers. > 2) The geronimo-addUrl shell command and related code is unnecessary. There > is already obr:addurl operation. > 3) When doing geronimo-install would be good to also specify whether the > optional resources should also be downloaded and installed. > 4) Can't ThreadPool be injected into ObrBundleInstallerGBean just like the > repository is (instead of doing Kernel lookup)? > 5) GeronimoGBean could also be injected instead of doing OSGi service > lookup. > 6) You shouldn't need to add LOCAL_OBR into repository. That's what > GeronimoOBRGBean does already. > 7) The filter created in ObrUtils.searchRepository() essentially specifies > to find a bundle with the given symbolic name and the minimal version. That > is, for example, the user specified foo,1.0 but the install might result in > installing foo,2.0. I think we want to match the exact version. Or maybe we > want to support version ranges. > 8) The way the code currently decides whether the resource is "local" or > not is not very reliable. So we might need to find another way or improve > Felix OBR.* > * > -------------------------------------------------------------------------- > * > > 1) I will add the license headers > 2) I think the geronimo-addurl command should record the urls into a file, > and geronimo-obr will read the urls and add them so I write the command, > however, I don't decide which file to write and read, do you think we need > to record the urls? > 3) Do you mean the "optional resources" is the dependencies of the target > bundle or something else? > 4), 5), 6) I will resolve it > 7) I've test the scenario you described and there is no such confusion. > However, I think support the version ranges is a good idea! > 8) Now the "local" resources are the ones whose url start with "mvn:". The > implementation is: When install a bundle, if the bundle is local, will > verify its existence, if not existed, will throw an exception; If the bundle > is remote, just download it and install it into geronimo repository. > > On Thu, Aug 11, 2011 at 1:23 PM, Jarek Gawor <[email protected]> wrote: > >> There is already obr:addurl command so obr:geronimo-addurl is >> unnecessary. I added all my comments to GERONIMO-5939. >> >> Jarek >> >> On Wed, Aug 10, 2011 at 10:24 PM, Yi Xiao <[email protected]> >> wrote: >> > Hi devs, >> > >> > Now, I want to add the support of OSGi bundle repository in Geronimo3.0, >> the >> > patch is available at: >> https://issues.apache.org/jira/browse/GERONIMO-5939 >> > I used Felix's OBR APIs to develop and add THREE karaf shells to >> control >> > the OBR in geronimo: >> > >> > 1 obr:geronimo-addurl url >> > Add a remote repository to the geronimo's repositoryAdmin. >> > >> > 2 obr:geronimo-install [--start | --startLevel num | -v] >> > symbolicName,version >> > Install a bundle into geronimo in OBR way. >> > first, resolve the bundle, if resolve failed, return directly and print >> the >> > unsatisfactory conditions to user; >> > second, download the bundle and its dependencies from the remote sites >> to >> > local; >> > third, deploy all the bundles into geronimo repository and install them >> into >> > OSGi framework; >> > finally, update the geronimo's obr.xml file. >> > >> > 3 obr:geronimo-uninstall symbolicName,version >> > Uninstall a bundle from geronimo in OBR way. >> > Compared with the osgi:uninstall, the OBR's uninstall will clean up the >> > geronimo's repository and startup.properties file, also update the >> obr.xml >> > file. >> > >> > Any suggestions ? >> > >> > -- >> > Best regards! >> > >> > John Xiao >> > >> > > > > -- > Best regards! > > > John Xiao > > > -- Best regards! John Xiao
