geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yi Xiao <xiaoyijhondeve...@gmail.com>
Subject Re: [DISCUSSION] The OBR feature in Geronimo3.0
Date Tue, 16 Aug 2011 01:10:53 GMT
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 <david_jencks@yahoo.com>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 <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
>>
>> <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 <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
>
>
>


-- 
Best regards!


               John Xiao

Mime
View raw message