Hi David, Ok, that's great! I've looked into the karaf's obr:intall command, I will discuss it in KARAF-814. Thanks, David.
On Tue, Aug 16, 2011 at 1:29 AM, David Jencks <[email protected]>wrote: > Hi Yi, > > I think the question of what should survive a clean start and what form the > info about it should take needs more discussion. > > I chatted with jbonofre and anierbeck about my understanding of what you > are trying to do and they'd like it in karaf and/or cave, they opened > https://issues.apache.org/jira/browse/KARAF-814. It would be great if you > could contribute to this discussion. > > thanks > david jencks > > On Aug 15, 2011, at 2:37 AM, Yi Xiao wrote: > > Hi David, > > The difference between the obr:deploy and the obr:geronimo-install is: > obr:deploy just install the bundle and the dependent bundles in OSGi > framework, if the server shutdown and start with -clean, the bundles will > not exist any more; The obr:geronimo-install will persist the bundles into > Geronimo's local repository if the bundle resource's url does not start with > "mvn:" > > The most common usage of the obr: geronimo-install shell command should be: > 1 the user already has or creates a new OBR repository; > 2 the user want to install a bundle in the OBR repository into our > Geronimo, and the bundle depends on lots of bundles(in this OBR or other > remote OBRs); > Now, the shell command will persist the bundles to Geronimo's local repo. > I think the advantage is when next startup of Geronimo server with -clean, > the user won't lost the target bundle and its dependencies. > It will be benefit when develop a bundle application that depends on lots > of other bundles, the user need not always download many bundles from remote > site. > > The Cave is a great tool and I've try it locally. > I think maybe we could use Cave to create the Geronimo's local repo, if > Geronimo want to adopt a more flexible repository management, the Cave will > be a good choice! > > On Mon, Aug 15, 2011 at 2:48 PM, David Jencks <[email protected]>wrote: > >> Hi Yi, >> >> I chatted with jbonofre a little bit on IRC and don't quite understand >> what you are trying to do. According to jbonofre, installing the set of >> resolved bundles suggested by obr is already implemented for a long time by >> >> obr:deploy >> >> and (as of yesterday?) >> >> osgi:install obr:id/version >> >> He also gave me this link to show cave in action a little bit.... it may >> not work for more than a day or so... >> http://pastie.org/2360003 >> >> My impression is that cave is oriented toward managing the set of remote >> repositories that are accessible to the obr resolver and that once the obr >> resolver has finished suggesting a set of bundles that satisfy the >> requirements then the "install bundles" step is already implemented. >> >> If the goals of your work are this close to the existing functionality and >> what is going into cave I really think that contributing to cave will be a >> better use of your time and make your work more widely useful. >> >> thanks >> david jencks >> >> <http://pastie.org/2360003> >> On Aug 11, 2011, at 11:13 PM, Yi Xiao wrote: >> >> Hi David, >> >> I look into the cave project, its target is to create a obr repository and >> the function is similar to geronimo-obr, >> However, the feature I want to add is when install a bundle to geronimo, >> should resolve and install its dependent bundles to ensure the target bundle >> resolve successfully. >> >> On Fri, Aug 12, 2011 at 1:18 PM, David Jencks <[email protected]>wrote: >> >>> I really think you should look at what karaf is doing in cave. I don't >>> think we really need two projects with such similar aims. >>> >>> For mvn: urls, the pax maven url handler will resolve and fetch mvn urls >>> from all the maven repos it knows about. Presumably you will have >>> configured pax-maven-url with the repos you are interested in accepting >>> artifacts from. >>> >>> why would geronimo need to parse the obr urls in etc/config.properties? >>> Doesn't whatever put them there know to look for them? >>> >>> thanks >>> david jencks >>> >>> On Aug 11, 2011, at 10:10 PM, Yi Xiao wrote: >>> >>> OK, the obr:addurl is greate! >>> >>> Should we parse the etc/config.properties to add the urls when the server >>> start up? >>> >>> For the "mvn" url, I will look into it and find a suitable way! >>> >>> thanks~ >>> >>> On Fri, Aug 12, 2011 at 12:28 PM, Jarek Gawor <[email protected]> wrote: >>> >>>> 2) obr:addurl is persistent. The obr urls are stored in the >>>> etc/config.properties file. >>>> 3) During obr resolution optional resources are discovered >>>> (resolver.getOptionalResources()). There should be an option to decide >>>> whether these optional resources should be installed as well. >>>> 8) You can't assume that resources with "mvn" url are local. >>>> >>>> Jarek >>>> >>>> On Thu, Aug 11, 2011 at 5:15 AM, Yi Xiao <[email protected]> >>>> 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 >>> >>> >>> >> >> >> -- >> Best regards! >> >> >> John Xiao >> >> >> > > > -- > Best regards! > > > John Xiao > > > -- Best regards! John Xiao
