maybe we can enable this:
#org.ops4j.pax.url.mvn.localRepository=${karaf.home}/repository2011/8/12 Rex Wang <[email protected]> > yes.. currently we only specify > org.ops4j.pax.url.mvn.defaultRepositories=file:${karaf.home}/repository@snapshots > so mvn: could be considered as a "local" bundle. > But, if user open the config: > #org.ops4j.pax.url.mvn.repositories= \ > # http://repo1.maven.org/maven2, \ > # > http://repository.apache.org/content/groups/snapshots-group@snapshots@noreleases, > \ > # http://repository.ops4j.org/maven2, \ > # http://svn.apache.org/repos/asf/servicemix/m2-repo, \ > # http://repository.springsource.com/maven/bundles/release, \ > # http://repository.springsource.com/maven/bundles/external > > mvn: might link to a remote resource. We might need figure out how to > download such resource to local.. > > -Rex > > > > 2011/8/12 Yi Xiao <[email protected]> > >> 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 >> >> > > > -- > Lei Wang (Rex) > rwonly AT apache.org > -- Lei Wang (Rex) rwonly AT apache.org
