geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [DISCUSSION] The OBR feature in Geronimo3.0
Date Mon, 15 Aug 2011 17:29:39 GMT
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 <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 
> 
> 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
> 
> 
> 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?
>> 
>> 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 <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.
>>> 
>>> Jarek
>>> 
>>> 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
> 


Mime
View raw message