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.

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 <david_jencks@yahoo.com> 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 


and (as of yesterday?)

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...

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.

david jencks

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 <david_jencks@yahoo.com> 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?

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!


On Fri, Aug 12, 2011 at 12:28 PM, Jarek Gawor <jgawor@gmail.com> 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.


On Thu, Aug 11, 2011 at 5:15 AM, Yi Xiao <xiaoyijhondevelop@gmail.com> 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 <jgawor@gmail.com> 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 <xiaoyijhondevelop@gmail.com>
>> 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