From dev-return-92354-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Fri Aug 12 05:21:38 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 E3799839C for ; Fri, 12 Aug 2011 05:21:37 +0000 (UTC) Received: (qmail 30904 invoked by uid 500); 12 Aug 2011 05:21:11 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 30731 invoked by uid 500); 12 Aug 2011 05:20:44 -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 28344 invoked by uid 99); 12 Aug 2011 05:19:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Aug 2011 05:19:22 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=FREEMAIL_FROM,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; Fri, 12 Aug 2011 05:19:14 +0000 Received: (qmail 53787 invoked from network); 12 Aug 2011 05:18:52 -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=2WMGxE5BrIKugUfvIFTZHUaAvEWiafJMLQwODLZ5HiuEMSHH7s5w+NL+1EOBKgBF6RMm8UIJ+HCh4kcYfP828uKVh3FhQ6T7Dvi5GFlnXhFjmeG+e6S2TwVeqttiLB9Da8NvXUJdIEc1BpuoyxCcy9BAEjs8ZzKSEwUNF4mLxlw= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313126332; bh=d/yZtDzOqljs27PVc9A6yi5g2ys0ZrI4d42gWhZbz00=; 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=sOzCPH4UrNzRkH9B/trr0+Fcg8cATCXwOJBNIThgXaqT+AWYRsyw9H8uDFmnWFuUkC94sOHXhBAwtea7PCKBPXBIIh4u0DhN05jhI4opoP5kIie+P2DznmKvEtTSoZlv2h7QORW7JhPHlHyVw2SCwQd5k9FrQqO96M+xYFCwexQ= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _IzQBY0VM1nllKl.yVL5pjAzjJEA2sTvMeUidQ_DzasehiV XD8dwPUOsAqdJhzIvoL90D5l7X6fi2gzpT5XqBJ9.v6t3lTAfwyvnjuHVzNt pjOH62wiNSVipjh1QImC47Djl1weGnoynj6Zn.pilESZMkjLExV06eeuDhJj edpFygVQ2CDJbqgZqNO4TQIsPwgVZXOkbN24fhruolYhHRLEszvQANL4HzZX 22LEFiVrpn8zhFlAm2C_cp6YVz5Uo.yhvbcqn8zIWyaBaEFDmCMDRgjIQeUz NvHKtKFHix0lah1hEeGy1l.KR4e_eP6HdLzAJgcRKhKHRJm9_POJVAFSjf2D Q5LUg8AYTGEiwhILzVswvHKd5NPSbZrzvaCbSwY9on1yx0N9KSZlD1XSSlHn dxWt0kyUgDf.VRxnoAlShvxA_tt4ytYjVC.Oyk78kqulcaA_8y9W83H5bcoU 1M.Gpj9r9v8DErC5jlVJK09VIXvqgSOkEAccr5OHG9K4ec9DzoChy0FP0Rxq uFU8uqD33HnU5 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; 11 Aug 2011 22:18:52 -0700 PDT From: David Jencks Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3--188317767 Subject: Re: [DISCUSSION] The OBR feature in Geronimo3.0 Date: Thu, 11 Aug 2011 22:18:51 -0700 In-Reply-To: To: dev@geronimo.apache.org References: Message-Id: <1142D705-96A8-4562-8FC9-B89BA87E2A52@yahoo.com> X-Mailer: Apple Mail (2.1084) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-3--188317767 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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! >=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 --Apple-Mail-3--188317767 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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


= --Apple-Mail-3--188317767--