Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Remote deployment

Hi Leen,

Leen Toelen wrote:
Hi Jan,

I know you've already written this for r-osgi, but do you think
there's a lot that needs to change for the ecf port? How would you do
an ecf implementation? How I see it (in the GUI at least) is that you
select a contact, send him the plugin, and the contact only has to

If you are sending a single plugin, this use case is provided by the ECF file transfer least the sending/receiving the bundle jar file. After receiving, to install the bundle in the local runtime requires using (e.g.) BundleContext.installBundle(...).

I don't know yet how we have to negotiate dependencies, because
you only want to send the files that are absolutely necessary.

This is where p2 would/does come in. In p2, the 'sender' would make available (or point to) meta-data and artifact repositories...that the receiver can then access during a p2-based install. The meta-data and artifact repositories are identified by a URL. The ECF filetransfer API is used *by p2* to actually retrieve the artifacts/jars from the artifact repository (note this is different from the case described above, where some appliction would explicitly initiate the file transfer for the plugin and to the install via installBundle).

p2 will do all the dependency resolution. That is, the p2 resolver will make sure that the necessary plugins (from meta-data repo) can be resolved and then downloaded and installed.

So for using p2, something like these steps would likely be involved

a) Sender sets up p2 meta-data and artifact repositories...and then publish them so they can be used during the receiver's p2-based install (via http for example) b) The sender has to communicate some URLs for the appropriate meta-data and artifact repositories to the receiver c) The sender has to communicate an 'installable unit' (aka IU a p2 concept) to the receiver d) Given the URLs from b, a working server from 'a', and the installable unit from 'c', the receiver can/could install the installable unit.

ECF can/could be used to communicate the URL and IU meta-data to the receiver (b and c), and have a user-level messaging dialog (e.g. do you want to install this?...etc). This could be done via ECF datashare API over IM, or the remote services API (which can use r-OSGi as an implementation, or XMPP, or others).

p2 uses ECF's filetransfer APIs for the p2 client to retrieve plugins from the artifact repository, so that will all be done transparently (i.e. via pull). With p2 you don't have to worry about transferring the files directly.
Does this make sense?

Jan...I know you haven't been involved-in/working on p2, but would this still fit in with your plans?



On Fri, Apr 11, 2008 at 12:09 AM, Jan S. Rellermeyer
<rellermeyer@xxxxxxxxxxx> wrote:
Hi Leen,

 unfortunately, I didn't get an application for this project but I would be
 very much interested to get somebody working on this. If we can't find a
 student via GSOC, I could try to announce the project as a lab or semester
 thesis at ETH but it then probably won't start before the fall semester.



 ETH Zurich, MSc Jan S. Rellermeyer,
 Information and Communication Systems Research Group (IKS),
 Department of Computer Science,
 IFW B 47.1, Haldeneggsteig 4, CH–8092 Zürich Tel +41 44 632 30 38,

 ecf-dev mailing list

ecf-dev mailing list

Back to the top