An alternative solution might be the apache karaf cellar project karaf.apache.org
Kind regards On Oct 10, 2011 10:32 AM, "Jean-Philippe Clement" < [email protected]> wrote: > => http://fabric.fusesource.org/ > > Kind regards, > Jean-Philippe > > Quoting DEBROUX Lionel <[email protected]>: > > Hello, >> >> I have a use case for deploying bundles (which may have transitive, >> versioned dependencies) accross several LAN nodes all installed with >> the Felix framework. >> >> The main goal is to have, for each node, the ability of: >> - (1) acting as a server for bundles towards other nodes >> - (2) downloading and installing bundles from other nodes, since all >> nodes provide (1) >> >> Each node would also be expected to: >> - (3) have every downloaded and/or installed bundle automatically >> appearing as available for download to other nodes. >> >> Therefore, the use case is a step beyond the standard model, where >> client nodes are in most cases constantly downloading from a known >> and predefined "central" OBR. >> The point is to: >> - enhance robustness, in case remote OBRs are unreachable when the >> need to deploy bundles to other nodes arise. >> - favor deployments within local node neighbourhood, by exposing >> bundles to a set of nearby nodes. >> >> Example: >> Nodes A, B and C belong to the same network neighbourhood N1 >> Nodes C, D and E belong to the same network neighbourhood N2 >> >> - C gets and deploys bundle Foo from E using (2) >> - as a member of both N1 and N2, bundle Foo becomes then available >> to all members of N1 and N2 because of (3) and (1) >> - E dies >> - A and B can get and deploy bundle Foo from C rather than from E. >> >> >> I'd like hints on how to best use the OBR infrastructure to achieve >> (1), (2) and especially (3). Maybe it needs to be modified ? >> Or maybe there are better solutions than the OBR infrastructure ? >> >> >> I looked at OBRs because the OBR client can download from multiple >> OBRs, and transitive dependencies are handled. >> However, I noticed that: >> * updating OBR XML files takes some work. There's the Maven plugin, >> but I'd rather not use that in production, there should be >> something leaner; >> * when deploying a bundle, ResolverImpl.deploy() calls >> BundleContext.installBundle() but does not keep a separate copy >> of the bundle, which I'd like to do; >> * dumping the local repository to XML form, through >> DataModelHelper.**writeRepository(), is easy, but there are no >> URIs for the bundles in there. As a consequence, even if I >> exposed the local repository XML file on the network, OBR >> clients wouldn't be able to install the bundles. >> >> For demo purposes, I can build a custom solution, starting by exposing >> through servlets directories containing bundles. In fact, I have been >> given some code that does just that. From that point, I have made some >> rough code to download and install individual bundles into the target >> framework. >> But for production use, I'll want to provide some higher-level >> information (bundle symbolic names, dependencies, etc.) and handle >> transitive dependencies... which brings me back to the already >> invented OBR wheel :) >> >> >> Thanks in advance for replies, >> Lionel. >> ______________________________**__ >> >> >> Ce message et les pièces jointes sont confidentiels et réservés à l'usage >> exclusif de ses destinataires. Il peut également être protégé par le secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne >> pouvant être assurée sur Internet, la responsabilité du groupe Atos ne >> pourra être engagée quant au contenu de ce message. Bien que les meilleurs >> efforts soient faits pour maintenir cette transmission exempte de tout >> virus, l'expéditeur ne donne aucune garantie à cet égard et sa >> responsabilité ne saurait être engagée pour tout dommage résultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As >> its integrity cannot be secured on the Internet, the Atos group liability >> cannot be triggered for the message content. Although the sender endeavors >> to maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. >> >> > > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@felix.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
