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 Fri, 12 Aug 2011 05:30:37 GMT
Ok, I will look cave first and decide to what to do. Thanks for you option.


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

Mime
View raw message