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 <[email protected]>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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected] >> > >> >> 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
