From dev-return-92388-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Mon Aug 15 17:30:13 2011 Return-Path: X-Original-To: apmail-geronimo-dev-archive@www.apache.org Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F34E9777C for ; Mon, 15 Aug 2011 17:30:12 +0000 (UTC) Received: (qmail 54673 invoked by uid 500); 15 Aug 2011 17:30:12 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 54164 invoked by uid 500); 15 Aug 2011 17:30:11 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 53981 invoked by uid 99); 15 Aug 2011 17:30:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 Aug 2011 17:30:11 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_FROM,HTML_FONT_FACE_BAD,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [98.136.44.58] (HELO smtp103.prem.mail.sp1.yahoo.com) (98.136.44.58) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 15 Aug 2011 17:30:04 +0000 Received: (qmail 5002 invoked from network); 15 Aug 2011 17:29:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer; b=hJnnpTAxAm1XPtTrqW6C+rpxFS85gMWEYeV1doY9D+gpY2jXLxxGTAshtHpLNA5fcCRCnFe5gpe/JZO2VEAOFZpEtwBrYui/RDnoOFHtx2Ep8Hq1rXIDd1vUjbJbLnmhMutn+Hq6VaWJ/cVh48QsjkgNW0RmY0pTJCUtFJz5Ywk= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313429381; bh=76kxBKjD+2TPGbl9CV4JC/sEQAdYfyA5byb1+7fsjok=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer; b=GUAYzio7tPvqp1w50QMGYmEfF+HxOXTFyyClOV06rJn34Ygos6MzT2jat/QFU7KyTiJPiC/PFttn/qEGCM2AmwrfA0WFri5+MZgAuW5p93JTY5nuNvjLkCLMYVwl4YjqpiGY/NHEDqAeaqCoKmkQm0gGBWhweIXvhxW/EC/WKuM= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: X0jCJLgVM1nJ4oj.RAUzkLqEG5nIkv7UMuTGH9EjU4HZ7YK 7J6nVQI0kYsDLq28zNbD3UWwTMhLFS7rUs00VKaEayDfEZVNkJQuJGJqIrKj 8r93FC6KQAGnIdYPZ4lRDX7a0Bc8l5YgHZ1WJ8ZMHzf.Znvl7rqpSLDdp6ff NbVLdg7jTZHwu66OuNXuXDfNZrEBGlhjHhjiLd.ieShc7fkdYl8kIkBom54g LRSaEVZjz4ROwuITqUjzHtFHGvuAfI8Ow5PDH9Gx5SnWmLVSPDMxHEw33aCc fm1dXos36jL2RRQpUt5fhX0MfdSRMW9UbsJZ_j4lkQrdjo.lTPFMV2xMXat2 8DuAjTN3Yr8LCWas7VCRUlIXBvpJQNOA9MlhurMfPfu7Xz6EJeL9.QTrkWYG L1Y5eZwf6gaH._5iRRvcw1hUF2I3otPLtJAp0dFvxEjUqFMoOR1TTbhgLy3m GKLLB0h82F1k0U1JA6pw28XllsImpST3g7IOXiQHigtJP5phlyqO4mbF62vZ yykRdN06ruRUNTqi9euQXhlmbuQ75OM3gp4bWYxlpOPemrcsjUpkgPfPF X-Yahoo-SMTP: .9oIUzyswBANsYgUm_5uPui0skTnzGJXJQ-- Received: from [10.0.1.4] (david_jencks@76.76.148.215 with plain) by smtp103.prem.mail.sp1.yahoo.com with SMTP; 15 Aug 2011 10:29:40 -0700 PDT From: David Jencks Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8-114730337 Subject: Re: [DISCUSSION] The OBR feature in Geronimo3.0 Date: Mon, 15 Aug 2011 10:29:39 -0700 In-Reply-To: To: dev@geronimo.apache.org References: <1142D705-96A8-4562-8FC9-B89BA87E2A52@yahoo.com> Message-Id: <99F5E884-8666-44DE-977D-0559DA86ED3D@yahoo.com> X-Mailer: Apple Mail (2.1084) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-8-114730337 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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, >=20 > 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:" >=20 > 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. >=20 > 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!=20 >=20 > On Mon, Aug 15, 2011 at 2:48 PM, David Jencks = wrote: > Hi Yi, >=20 > 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=20 >=20 > obr:deploy >=20 > and (as of yesterday?) >=20 > osgi:install obr:id/version >=20 > 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 >=20 > 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. >=20 > 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. >=20 > thanks > david jencks >=20 >=20 > On Aug 11, 2011, at 11:13 PM, Yi Xiao wrote: >=20 >> Hi David, >>=20 >> I look into the cave project, its target is to create a obr = repository and the function is similar to geronimo-obr,=20 >> 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. >>=20 >> On Fri, Aug 12, 2011 at 1:18 PM, David Jencks = 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. >>=20 >> 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. >>=20 >> why would geronimo need to parse the obr urls in = etc/config.properties? Doesn't whatever put them there know to look = for them? >>=20 >> thanks >> david jencks >>=20 >> On Aug 11, 2011, at 10:10 PM, Yi Xiao wrote: >>=20 >>> OK, the obr:addurl is greate! >>>=20 >>> Should we parse the etc/config.properties to add the urls when the = server start up? >>>=20 >>> For the "mvn" url, I will look into it and find a suitable way!=20 >>>=20 >>> thanks~ >>>=20 >>> On Fri, Aug 12, 2011 at 12:28 PM, Jarek Gawor = 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. >>>=20 >>> Jarek >>>=20 >>> On Thu, Aug 11, 2011 at 5: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 = 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 = >>> >> 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 >>> > >>>=20 >>>=20 >>>=20 >>> --=20 >>> Best regards! >>>=20 >>> = John Xiao >>>=20 >>=20 >>=20 >>=20 >>=20 >> --=20 >> Best regards! >>=20 >> = John Xiao >>=20 >=20 >=20 >=20 >=20 > --=20 > Best regards! >=20 > = John Xiao >=20 --Apple-Mail-8-114730337 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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.ap= ache.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?)


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.

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<= br> >> > 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


= --Apple-Mail-8-114730337--